요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.
1. 요약·해설
원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.
sysfs 상태와 완화
tsx_async_abort.rst:84-142TAA 상태 문자열 5개, 최선 노력 모드와 호스트·게스트 가상화 조건을 설명합니다.
커널 명령줄 제어
tsx_async_abort.rst:143-238`tsx_async_abort=`와 `tsx=` 옵션, VERW, SMT, CPUID·MSR 조합별 결과를 비교합니다.
운영 선택 기준
tsx_async_abort.rst:239-270사용자 공간과 게스트의 신뢰 수준에 따른 선택 및 기본 `tsx_async_abort=full tsx=off` 정책을 설명합니다.
2. 영어 원문 전체
번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.
원문 전체 펼치기
.. SPDX-License-Identifier: GPL-2.0
TAA - TSX Asynchronous Abort
======================================
TAA is a hardware vulnerability that allows unprivileged speculative access to
data which is available in various CPU internal buffers by using asynchronous
aborts within an Intel TSX transactional region.
Affected processors
-------------------
This vulnerability only affects Intel processors that support Intel
Transactional Synchronization Extensions (TSX) when the TAA_NO bit (bit 8)
is 0 in the IA32_ARCH_CAPABILITIES MSR. On processors where the MDS_NO bit
(bit 5) is 0 in the IA32_ARCH_CAPABILITIES MSR, the existing MDS mitigations
also mitigate against TAA.
Whether a processor is affected or not can be read out from the TAA
vulnerability file in sysfs. See :ref:`tsx_async_abort_sys_info`.
Related CVEs
------------
The following CVE entry is related to this TAA issue:
============== ===== ===================================================
CVE-2019-11135 TAA TSX Asynchronous Abort (TAA) condition on some
microprocessors utilizing speculative execution may
allow an authenticated user to potentially enable
information disclosure via a side channel with
local access.
============== ===== ===================================================
Problem
-------
When performing store, load or L1 refill operations, processors write
data into temporary microarchitectural structures (buffers). The data in
those buffers can be forwarded to load operations as an optimization.
Intel TSX is an extension to the x86 instruction set architecture that adds
hardware transactional memory support to improve performance of multi-threaded
software. TSX lets the processor expose and exploit concurrency hidden in an
application due to dynamically avoiding unnecessary synchronization.
TSX supports atomic memory transactions that are either committed (success) or
aborted. During an abort, operations that happened within the transactional region
are rolled back. An asynchronous abort takes place, among other options, when a
different thread accesses a cache line that is also used within the transactional
region when that access might lead to a data race.
Immediately after an uncompleted asynchronous abort, certain speculatively
executed loads may read data from those internal buffers and pass it to dependent
operations. This can be then used to infer the value via a cache side channel
attack.
Because the buffers are potentially shared between Hyper-Threads cross
Hyper-Thread attacks are possible.
The victim of a malicious actor does not need to make use of TSX. Only the
attacker needs to begin a TSX transaction and raise an asynchronous abort
which in turn potentially leaks data stored in the buffers.
More detailed technical information is available in the TAA specific x86
architecture section: :ref:`Documentation/arch/x86/tsx_async_abort.rst <tsx_async_abort>`.
Attack scenarios
----------------
Attacks against the TAA vulnerability can be implemented from unprivileged
applications running on hosts or guests.
As for MDS, the attacker has no control over the memory addresses that can
be leaked. Only the victim is responsible for bringing data to the CPU. As
a result, the malicious actor has to sample as much data as possible and
then postprocess it to try to infer any useful information from it.
A potential attacker only has read access to the data. Also, there is no direct
privilege escalation by using this technique.
.. _tsx_async_abort_sys_info:
TAA system information
-----------------------
The Linux kernel provides a sysfs interface to enumerate the current TAA status
of mitigated systems. The relevant sysfs file is:
/sys/devices/system/cpu/vulnerabilities/tsx_async_abort
The possible values in this file are:
.. list-table::
* - 'Vulnerable'
- The CPU is affected by this vulnerability and the microcode and kernel mitigation are not applied.
* - 'Vulnerable: Clear CPU buffers attempted, no microcode'
- The processor is vulnerable but microcode is not updated. The
mitigation is enabled on a best effort basis.
If the processor is vulnerable but the availability of the microcode
based mitigation mechanism is not advertised via CPUID, the kernel
selects a best effort mitigation mode. This mode invokes the mitigation
instructions without a guarantee that they clear the CPU buffers.
This is done to address virtualization scenarios where the host has the
microcode update applied, but the hypervisor is not yet updated to
expose the CPUID to the guest. If the host has updated microcode the
protection takes effect; otherwise a few CPU cycles are wasted
pointlessly.
* - 'Mitigation: Clear CPU buffers'
- The microcode has been updated to clear the buffers. TSX is still enabled.
* - 'Mitigation: TSX disabled'
- TSX is disabled.
* - 'Not affected'
- The CPU is not affected by this issue.
Mitigation mechanism
--------------------
The kernel detects the affected CPUs and the presence of the microcode which is
required. If a CPU is affected and the microcode is available, then the kernel
enables the mitigation by default.
The mitigation can be controlled at boot time via a kernel command line option.
See :ref:`taa_mitigation_control_command_line`.
Virtualization mitigation
^^^^^^^^^^^^^^^^^^^^^^^^^
Affected systems where the host has TAA microcode and TAA is mitigated by
having disabled TSX previously, are not vulnerable regardless of the status
of the VMs.
In all other cases, if the host either does not have the TAA microcode or
the kernel is not mitigated, the system might be vulnerable.
.. _taa_mitigation_control_command_line:
Mitigation control on the kernel command line
---------------------------------------------
The kernel command line allows to control the TAA mitigations at boot time with
the option "tsx_async_abort=". The valid arguments for this option are:
============ =============================================================
off This option disables the TAA mitigation on affected platforms.
If the system has TSX enabled (see next parameter) and the CPU
is affected, the system is vulnerable.
full TAA mitigation is enabled. If TSX is enabled, on an affected
system it will clear CPU buffers on ring transitions. On
systems which are MDS-affected and deploy MDS mitigation,
TAA is also mitigated. Specifying this option on those
systems will have no effect.
full,nosmt The same as tsx_async_abort=full, with SMT disabled on
vulnerable CPUs that have TSX enabled. This is the complete
mitigation. When TSX is disabled, SMT is not disabled because
CPU is not vulnerable to cross-thread TAA attacks.
============ =============================================================
Not specifying this option is equivalent to "tsx_async_abort=full". For
processors that are affected by both TAA and MDS, specifying just
"tsx_async_abort=off" without an accompanying "mds=off" will have no
effect as the same mitigation is used for both vulnerabilities.
The kernel command line also allows to control the TSX feature using the
parameter "tsx=" on CPUs which support TSX control. MSR_IA32_TSX_CTRL is used
to control the TSX feature and the enumeration of the TSX feature bits (RTM
and HLE) in CPUID.
The valid options are:
============ =============================================================
off Disables TSX on the system.
Note that this option takes effect only on newer CPUs which are
not vulnerable to MDS, i.e., have MSR_IA32_ARCH_CAPABILITIES.MDS_NO=1
and which get the new IA32_TSX_CTRL MSR through a microcode
update. This new MSR allows for the reliable deactivation of
the TSX functionality.
on Enables TSX.
Although there are mitigations for all known security
vulnerabilities, TSX has been known to be an accelerator for
several previous speculation-related CVEs, and so there may be
unknown security risks associated with leaving it enabled.
auto Disables TSX if X86_BUG_TAA is present, otherwise enables TSX
on the system.
============ =============================================================
Not specifying this option is equivalent to "tsx=off".
The following combinations of the "tsx_async_abort" and "tsx" are possible. For
affected platforms tsx=auto is equivalent to tsx=off and the result will be:
========= ========================== =========================================
tsx=on tsx_async_abort=full The system will use VERW to clear CPU
buffers. Cross-thread attacks are still
possible on SMT machines.
tsx=on tsx_async_abort=full,nosmt As above, cross-thread attacks on SMT
mitigated.
tsx=on tsx_async_abort=off The system is vulnerable.
tsx=off tsx_async_abort=full TSX might be disabled if microcode
provides a TSX control MSR. If so,
system is not vulnerable.
tsx=off tsx_async_abort=full,nosmt Ditto
tsx=off tsx_async_abort=off ditto
========= ========================== =========================================
For unaffected platforms "tsx=on" and "tsx_async_abort=full" does not clear CPU
buffers. For platforms without TSX control (MSR_IA32_ARCH_CAPABILITIES.MDS_NO=0)
"tsx" command line argument has no effect.
For the affected platforms below table indicates the mitigation status for the
combinations of CPUID bit MD_CLEAR and IA32_ARCH_CAPABILITIES MSR bits MDS_NO
and TSX_CTRL_MSR.
======= ========= ============= ========================================
MDS_NO MD_CLEAR TSX_CTRL_MSR Status
======= ========= ============= ========================================
0 0 0 Vulnerable (needs microcode)
0 1 0 MDS and TAA mitigated via VERW
1 1 0 MDS fixed, TAA vulnerable if TSX enabled
because MD_CLEAR has no meaning and
VERW is not guaranteed to clear buffers
1 X 1 MDS fixed, TAA can be mitigated by
VERW or TSX_CTRL_MSR
======= ========= ============= ========================================
Mitigation selection guide
--------------------------
1. Trusted userspace and guests
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
If all user space applications are from a trusted source and do not execute
untrusted code which is supplied externally, then the mitigation can be
disabled. The same applies to virtualized environments with trusted guests.
2. Untrusted userspace and guests
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
If there are untrusted applications or guests on the system, enabling TSX
might allow a malicious actor to leak data from the host or from other
processes running on the same physical core.
If the microcode is available and the TSX is disabled on the host, attacks
are prevented in a virtualized environment as well, even if the VMs do not
explicitly enable the mitigation.
.. _taa_default_mitigations:
Default mitigations
-------------------
The kernel's default action for vulnerable processors is:
- Deploy TSX disable mitigation (tsx_async_abort=full tsx=off).
3. 한국어 전문 번역
영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.
TAA 개요, 영향받는 프로세서와 CVE
1-34이 문서는 `GPL-2.0` SPDX 라이선스로 제공됩니다.
TAA(TSX Asynchronous Abort)는 Intel TSX 트랜잭션 영역 안에서 비동기 중단을 일으켜 여러 CPU 내부 버퍼의 데이터에 비권한 추측 접근을 허용하는 하드웨어 취약점입니다.
영향받는 프로세서
이 취약점은 Intel Transactional Synchronization Extensions(TSX)를 지원하면서 `IA32_ARCH_CAPABILITIES` MSR의 `TAA_NO` 비트, 즉 비트 8이 `0`인 Intel 프로세서에만 영향을 줍니다. 같은 MSR의 `MDS_NO` 비트, 즉 비트 5가 `0`인 프로세서에서는 기존 MDS 완화가 TAA도 완화합니다.
프로세서가 영향을 받는지는 sysfs의 TAA 취약점 파일에서 확인할 수 있습니다. 아래의 `TAA 시스템 정보` 절을 참조하십시오.
관련 CVE
다음 CVE 항목이 TAA 문제와 관련됩니다.
| CVE | 이름 | 설명 |
|---|---|---|
| CVE-2019-11135 | TAA | 추측 실행을 사용하는 일부 마이크로프로세서의 TSX Asynchronous Abort(TAA) 조건으로 인해 인증된 사용자가 로컬 접근을 통해 부채널로 정보를 노출할 가능성이 있습니다. |
TAA 문제의 작동 원리
35-68문제
프로세서는 store, load 또는 L1 refill 연산을 수행할 때 임시 마이크로아키텍처 구조, 즉 버퍼에 데이터를 씁니다. 최적화를 위해 이 버퍼의 데이터가 load 연산으로 전달될 수 있습니다.
Intel TSX는 멀티스레드 소프트웨어 성능을 높이기 위해 하드웨어 트랜잭션 메모리 지원을 추가한 x86 명령어 집합 아키텍처 확장입니다. TSX는 불필요한 동기화를 동적으로 피함으로써 응용 프로그램 안에 감춰진 동시성을 프로세서가 드러내고 활용하게 합니다.
TSX는 성공하여 commit되거나 abort되는 원자적 메모리 트랜잭션을 지원합니다. abort가 발생하면 트랜잭션 영역 안에서 수행한 연산이 롤백됩니다. 다른 스레드가 트랜잭션 영역에서 사용 중인 캐시 라인에 접근하고 그 접근이 데이터 경쟁으로 이어질 수 있는 경우 등이 비동기 abort를 일으킵니다.
완료되지 않은 비동기 abort 직후 일부 추측 실행 load는 내부 버퍼의 데이터를 읽어 의존 연산에 전달할 수 있습니다. 그러면 캐시 부채널 공격으로 그 값을 추론할 수 있습니다.
버퍼가 하이퍼스레드 사이에서 공유될 가능성이 있으므로 하이퍼스레드 간 공격도 가능합니다.
악성 행위자의 피해자는 TSX를 사용할 필요가 없습니다. 공격자만 TSX 트랜잭션을 시작하고 비동기 abort를 일으키면 되며, 그 결과 버퍼에 저장된 데이터가 노출될 수 있습니다.
더 자세한 기술 정보는 TAA 전용 x86 아키텍처 문서 `Documentation/arch/x86/tsx_async_abort.rst`의 `tsx_async_abort` 절에 있습니다.
공격 시나리오와 TAA 시스템 정보
69-120공격 시나리오
TAA 취약점 공격은 호스트 또는 게스트에서 실행되는 비권한 응용 프로그램으로 구현할 수 있습니다.
MDS와 마찬가지로 공격자는 유출되는 메모리 주소를 제어하지 못합니다. 데이터를 CPU로 가져오는 주체는 피해자뿐입니다. 따라서 악성 행위자는 가능한 한 많은 데이터를 샘플링한 뒤 후처리하여 유용한 정보를 추론해야 합니다.
공격자는 데이터에 대한 읽기 접근만 얻습니다. 또한 이 기법 자체로 직접 권한 상승이 발생하지는 않습니다.
TAA 시스템 정보
원문의 `tsx_async_abort_sys_info` 앵커는 이 절을 가리킵니다.
Linux 커널은 완화된 시스템의 현재 TAA 상태를 열거하는 sysfs 인터페이스를 제공합니다. 관련 파일은 다음과 같습니다.
/sys/devices/system/cpu/vulnerabilities/tsx_async_abort이 파일에 가능한 값은 다음과 같습니다.
| 상태 | 의미 |
|---|---|
| Vulnerable | CPU가 취약점의 영향을 받으며 마이크로코드와 커널 완화가 적용되지 않았습니다. |
| Vulnerable: Clear CPU buffers attempted, no microcode | 프로세서가 취약하지만 마이크로코드가 업데이트되지 않았습니다. 최선 노력 방식으로 완화를 활성화합니다. |
| Mitigation: Clear CPU buffers | 버퍼를 지우도록 마이크로코드를 업데이트했습니다. TSX는 계속 활성화되어 있습니다. |
| Mitigation: TSX disabled | TSX가 비활성화되어 있습니다. |
| Not affected | CPU가 이 문제의 영향을 받지 않습니다. |
프로세서가 취약하지만 마이크로코드 기반 완화 기능이 CPUID를 통해 알려지지 않으면 커널은 최선 노력 완화 모드를 선택합니다. 이 모드는 CPU 버퍼가 지워진다는 보장 없이 완화 명령을 호출합니다.
이는 호스트에는 마이크로코드 업데이트가 적용되었지만 하이퍼바이저가 아직 게스트에 해당 CPUID를 노출하도록 업데이트되지 않은 가상화 시나리오를 다루기 위한 것입니다. 호스트 마이크로코드가 업데이트되었다면 보호가 적용되고, 그렇지 않으면 CPU 사이클 몇 개만 의미 없이 소비합니다.
완화 메커니즘과 가상화
121-142완화 메커니즘
커널은 영향을 받는 CPU와 필요한 마이크로코드의 존재를 감지합니다. CPU가 영향을 받고 마이크로코드를 사용할 수 있으면 기본적으로 완화를 활성화합니다.
부팅할 때 커널 명령줄 옵션으로 완화를 제어할 수 있습니다. 아래의 `커널 명령줄 완화 제어` 절을 참조하십시오.
가상화 완화
호스트에 TAA 마이크로코드가 있고 이전에 TSX를 비활성화하여 TAA를 완화한 영향 대상 시스템은 VM 상태와 관계없이 취약하지 않습니다.
그 밖의 모든 경우에 호스트에 TAA 마이크로코드가 없거나 커널이 완화되지 않았다면 시스템이 취약할 수 있습니다.
tsx_async_abort= 커널 명령줄 제어
143-171원문의 `taa_mitigation_control_command_line` 앵커는 이 절을 가리킵니다.
커널 명령줄의 완화 제어
커널 명령줄의 `tsx_async_abort=` 옵션으로 부팅 시 TAA 완화를 제어할 수 있습니다. 유효한 인수는 다음과 같습니다.
| 인수 | 동작 |
|---|---|
| off | 영향받는 플랫폼에서 TAA 완화를 비활성화합니다. 시스템에서 TSX가 활성화되어 있고 CPU가 영향을 받으면 시스템은 취약합니다. |
| full | TAA 완화를 활성화합니다. 영향받는 시스템에서 TSX가 켜져 있으면 ring 전환 시 CPU 버퍼를 지웁니다. MDS의 영향을 받고 MDS 완화를 적용한 시스템에서는 TAA도 이미 완화되므로 이 옵션은 효과가 없습니다. |
| full,nosmt | `tsx_async_abort=full`과 같지만 TSX가 활성화된 취약 CPU에서 SMT도 비활성화합니다. 이것이 완전한 완화입니다. TSX가 비활성화되면 스레드 간 TAA 공격에 취약하지 않으므로 SMT를 끄지 않습니다. |
이 옵션을 지정하지 않는 것은 `tsx_async_abort=full`과 같습니다. TAA와 MDS 모두의 영향을 받는 프로세서에서 `mds=off` 없이 `tsx_async_abort=off`만 지정하면 두 취약점이 같은 완화를 사용하므로 효과가 없습니다.
tsx= 제어와 완화 조합
172-238TSX 제어를 지원하는 CPU에서는 커널 명령줄 매개변수 `tsx=`로 TSX 기능도 제어할 수 있습니다. `MSR_IA32_TSX_CTRL`은 TSX 기능과 CPUID의 TSX 기능 비트인 RTM 및 HLE 열거를 제어합니다.
유효한 옵션은 다음과 같습니다.
| 인수 | 동작 |
|---|---|
| off | 시스템에서 TSX를 비활성화합니다. 이 옵션은 MDS에 취약하지 않아 `MSR_IA32_ARCH_CAPABILITIES.MDS_NO=1`이고, 마이크로코드 업데이트로 새 `IA32_TSX_CTRL` MSR을 얻은 최신 CPU에서만 효과가 있습니다. 새 MSR은 TSX 기능을 신뢰성 있게 비활성화합니다. |
| on | TSX를 활성화합니다. 알려진 모든 보안 취약점에 대한 완화가 있지만 TSX는 과거 여러 추측 실행 관련 CVE의 공격을 가속한 것으로 알려졌으므로, 활성화한 채 두면 알려지지 않은 보안 위험이 있을 수 있습니다. |
| auto | `X86_BUG_TAA`가 있으면 TSX를 비활성화하고, 그렇지 않으면 시스템에서 TSX를 활성화합니다. |
이 옵션을 지정하지 않는 것은 `tsx=off`와 같습니다.
`tsx_async_abort`와 `tsx`는 다음과 같이 조합할 수 있습니다. 영향받는 플랫폼에서 `tsx=auto`는 `tsx=off`와 같습니다.
| TSX | TAA 완화 | 결과 |
|---|---|---|
| tsx=on | tsx_async_abort=full | VERW로 CPU 버퍼를 지웁니다. SMT 시스템에서는 스레드 간 공격이 여전히 가능합니다. |
| tsx=on | tsx_async_abort=full,nosmt | 위와 같지만 SMT 스레드 간 공격도 완화합니다. |
| tsx=on | tsx_async_abort=off | 시스템이 취약합니다. |
| tsx=off | tsx_async_abort=full | 마이크로코드가 TSX 제어 MSR을 제공하면 TSX가 비활성화될 수 있으며, 이 경우 시스템은 취약하지 않습니다. |
| tsx=off | tsx_async_abort=full,nosmt | 바로 위와 같습니다. |
| tsx=off | tsx_async_abort=off | 바로 위와 같습니다. |
영향받지 않는 플랫폼에서는 `tsx=on`과 `tsx_async_abort=full`을 사용해도 CPU 버퍼를 지우지 않습니다. TSX 제어가 없는 플랫폼, 즉 `MSR_IA32_ARCH_CAPABILITIES.MDS_NO=0`에서는 `tsx` 명령줄 인수가 효과가 없습니다.
영향받는 플랫폼에서 다음 표는 CPUID의 `MD_CLEAR` 비트와 `IA32_ARCH_CAPABILITIES` MSR의 `MDS_NO`, `TSX_CTRL_MSR` 비트 조합에 따른 완화 상태를 보여 줍니다.
| MDS_NO | MD_CLEAR | TSX_CTRL_MSR | 상태 |
|---|---|---|---|
| 0 | 0 | 0 | 취약합니다. 마이크로코드가 필요합니다. |
| 0 | 1 | 0 | VERW로 MDS와 TAA를 완화합니다. |
| 1 | 1 | 0 | MDS는 수정되었지만 TSX가 활성화되면 TAA에 취약합니다. `MD_CLEAR`에 의미가 없고 VERW가 버퍼를 지운다고 보장되지 않기 때문입니다. |
| 1 | X | 1 | MDS는 수정되었고 VERW 또는 `TSX_CTRL_MSR`로 TAA를 완화할 수 있습니다. |
완화 선택 가이드와 기본값
239-270완화 선택 가이드
1. 신뢰할 수 있는 사용자 공간과 게스트
모든 사용자 공간 응용 프로그램이 신뢰할 수 있는 출처에서 왔고 외부에서 제공된 신뢰할 수 없는 코드를 실행하지 않는다면 완화를 비활성화할 수 있습니다. 신뢰할 수 있는 게스트만 사용하는 가상화 환경에도 같은 판단을 적용할 수 있습니다.
2. 신뢰할 수 없는 사용자 공간과 게스트
시스템에 신뢰할 수 없는 응용 프로그램이나 게스트가 있다면 TSX를 활성화했을 때 악성 행위자가 호스트 또는 같은 물리 코어에서 실행되는 다른 프로세스의 데이터를 유출할 수 있습니다.
마이크로코드를 사용할 수 있고 호스트에서 TSX를 비활성화했다면 VM이 명시적으로 완화를 활성화하지 않아도 가상화 환경의 공격을 막습니다.
기본 완화
원문의 `taa_default_mitigations` 앵커는 이 절을 가리킵니다.
취약한 프로세서에 대한 커널의 기본 동작은 다음과 같습니다.
- TSX 비활성화 완화를 적용합니다: `tsx_async_abort=full tsx=off`.
취약점과 공격 모델
tsx_async_abort.rst:1-83영향받는 Intel TSX CPU, CVE, 내부 버퍼 전달과 비동기 abort를 이용한 데이터 샘플링 원리를 정리합니다.