← Documents Documentation/admin-guide/hw-vuln/cross-thread-rsb.rst GitHub 원문 ↗

Linux 6.18.37 · Administration / Hardware Vulnerabilities

Cross-Thread Return Address Predictions

AMD·Hygon SMT의 1T/2T 전환에서 sibling RSB 예측이 섞이는 문제와 kernel·KVM 완화를 설명합니다.

Source pathDocumentation/admin-guide/hw-vuln/cross-thread-rsb.rst
Source versionLinux v6.18.37
TranslationDUJINLABS 전문 번역 + 해설

요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.

1. 요약·해설

원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.

취약점과 공격 모델

cross-thread-rsb.rst:1-64

영향받는 CPU, CVE, RAP partition 전환과 guest가 제어한 반환 대상이 소비되는 조건을 정리합니다.

RSB와 KVM 완화

cross-thread-rsb.rst:65-91

context switch의 RSB 채우기, HLT·MWAIT interception, `mitigate_smt_rsb` 제어를 설명합니다.

2. 영어 원문 전체

번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.

원문 전체 펼치기
1
2 .. SPDX-License-Identifier: GPL-2.0
3
4 Cross-Thread Return Address Predictions
5 =======================================
6
7 Certain AMD and Hygon processors are subject to a cross-thread return address
8 predictions vulnerability. When running in SMT mode and one sibling thread
9 transitions out of C0 state, the other sibling thread could use return target
10 predictions from the sibling thread that transitioned out of C0.
11
12 The Spectre v2 mitigations protect the Linux kernel, as it fills the return
13 address prediction entries with safe targets when context switching to the idle
14 thread. However, KVM does allow a VMM to prevent exiting guest mode when
15 transitioning out of C0. This could result in a guest-controlled return target
16 being consumed by the sibling thread.
17
18 Affected processors
19 -------------------
20
21 The following CPUs are vulnerable:
22
23 - AMD Family 17h processors
24 - Hygon Family 18h processors
25
26 Related CVEs
27 ------------
28
29 The following CVE entry is related to this issue:
30
31 ============== =======================================
32 CVE-2022-27672 Cross-Thread Return Address Predictions
33 ============== =======================================
34
35 Problem
36 -------
37
38 Affected SMT-capable processors support 1T and 2T modes of execution when SMT
39 is enabled. In 2T mode, both threads in a core are executing code. For the
40 processor core to enter 1T mode, it is required that one of the threads
41 requests to transition out of the C0 state. This can be communicated with the
42 HLT instruction or with an MWAIT instruction that requests non-C0.
43 When the thread re-enters the C0 state, the processor transitions back
44 to 2T mode, assuming the other thread is also still in C0 state.
45
46 In affected processors, the return address predictor (RAP) is partitioned
47 depending on the SMT mode. For instance, in 2T mode each thread uses a private
48 16-entry RAP, but in 1T mode, the active thread uses a 32-entry RAP. Upon
49 transition between 1T/2T mode, the RAP contents are not modified but the RAP
50 pointers (which control the next return target to use for predictions) may
51 change. This behavior may result in return targets from one SMT thread being
52 used by RET predictions in the sibling thread following a 1T/2T switch. In
53 particular, a RET instruction executed immediately after a transition to 1T may
54 use a return target from the thread that just became idle. In theory, this
55 could lead to information disclosure if the return targets used do not come
56 from trustworthy code.
57
58 Attack scenarios
59 ----------------
60
61 An attack can be mounted on affected processors by performing a series of CALL
62 instructions with targeted return locations and then transitioning out of C0
63 state.
64
65 Mitigation mechanism
66 --------------------
67
68 Before entering idle state, the kernel context switches to the idle thread. The
69 context switch fills the RAP entries (referred to as the RSB in Linux) with safe
70 targets by performing a sequence of CALL instructions.
71
72 Prevent a guest VM from directly putting the processor into an idle state by
73 intercepting HLT and MWAIT instructions.
74
75 Both mitigations are required to fully address this issue.
76
77 Mitigation control on the kernel command line
78 ---------------------------------------------
79
80 Use existing Spectre v2 mitigations that will fill the RSB on context switch.
81
82 Mitigation control for KVM - module parameter
83 ---------------------------------------------
84
85 By default, the KVM hypervisor mitigates this issue by intercepting guest
86 attempts to transition out of C0. A VMM can use the KVM_CAP_X86_DISABLE_EXITS
87 capability to override those interceptions, but since this is not common, the
88 mitigation that covers this path is not enabled by default.
89
90 The mitigation for the KVM_CAP_X86_DISABLE_EXITS capability can be turned on
91 using the boolean module parameter mitigate_smt_rsb, e.g. ``kvm.mitigate_smt_rsb=1``.
92

3. 한국어 전문 번역

영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.

교차 스레드 반환 주소 예측

1-17

일부 AMD 및 Hygon 프로세서는 교차 스레드 반환 주소 예측 취약점의 영향을 받습니다. SMT 모드에서 한 sibling 스레드가 C0 상태를 벗어나면, 다른 sibling 스레드가 C0를 벗어난 스레드의 반환 대상 예측을 사용할 수 있습니다.

Spectre v2 완화는 idle 스레드로 context switch할 때 반환 주소 예측 항목을 안전한 대상으로 채우므로 Linux 커널을 보호합니다. 그러나 KVM에서는 VMM이 C0를 벗어날 때 guest mode를 종료하지 않도록 할 수 있습니다. 그러면 guest가 제어한 반환 대상이 sibling 스레드에서 소비될 수 있습니다.

영향받는 프로세서와 CVE

18-34

다음 CPU가 이 취약점의 영향을 받습니다.

  • AMD Family 17h 프로세서
  • Hygon Family 18h 프로세서
CVE관련 문제
CVE-2022-27672Cross-Thread Return Address Predictions

1T와 2T 전환에서 발생하는 문제

35-57

영향받는 SMT 지원 프로세서는 SMT가 켜졌을 때 1T 및 2T 실행 모드를 지원합니다. 2T 모드에서는 한 core의 두 스레드가 모두 코드를 실행합니다. core가 1T 모드에 들어가려면 한 스레드가 C0 상태를 벗어나도록 요청해야 합니다. 이는 `HLT` 명령이나 non-C0를 요청하는 `MWAIT` 명령으로 알릴 수 있습니다. 그 스레드가 C0에 다시 들어오고 다른 스레드도 여전히 C0에 있으면 프로세서는 2T 모드로 돌아갑니다.

영향받는 프로세서에서 반환 주소 예측기(RAP)는 SMT 모드에 따라 분할됩니다. 예를 들어 2T 모드에서는 각 스레드가 전용 16-entry RAP를 사용하지만, 1T 모드에서는 활성 스레드가 32-entry RAP를 사용합니다.

1T와 2T 사이를 전환할 때 RAP 내용은 바뀌지 않지만 다음 반환 예측 대상을 제어하는 RAP pointer는 바뀔 수 있습니다. 따라서 1T/2T 전환 뒤 한 SMT 스레드의 반환 대상이 sibling 스레드의 `RET` 예측에 사용될 수 있습니다. 특히 1T로 전환한 직후 실행한 `RET`는 막 idle 상태가 된 스레드의 반환 대상을 사용할 수 있습니다. 그 대상이 신뢰할 수 있는 코드에서 오지 않았다면 이론적으로 정보가 노출될 수 있습니다.

공격 시나리오와 완화 메커니즘

58-76

공격자는 의도한 반환 위치를 갖는 일련의 `CALL` 명령을 실행한 다음 C0 상태를 벗어나는 방식으로 영향을 받는 프로세서를 공격할 수 있습니다.

커널은 idle 상태에 들어가기 전에 idle 스레드로 context switch합니다. 이 context switch는 일련의 `CALL` 명령을 실행해 RAP 항목, 즉 Linux에서 RSB라고 부르는 항목을 안전한 대상으로 채웁니다.

또한 `HLT`와 `MWAIT` 명령을 가로채 guest VM이 프로세서를 직접 idle 상태로 만들지 못하게 해야 합니다. 이 문제를 완전히 해결하려면 RSB 채우기와 guest idle 진입 차단이 모두 필요합니다.

커널과 KVM 완화 제어

77-91

커널 command line에서는 context switch 때 RSB를 채우는 기존 Spectre v2 완화를 사용합니다.

KVM hypervisor는 기본적으로 guest가 C0를 벗어나려는 시도를 가로채 이 문제를 완화합니다. VMM은 `KVM_CAP_X86_DISABLE_EXITS` capability로 이 interception을 무시할 수 있지만, 이 사용 방식은 일반적이지 않으므로 해당 경로를 보호하는 완화는 기본으로 켜지지 않습니다.

`KVM_CAP_X86_DISABLE_EXITS` 사용 경로까지 완화하려면 boolean module parameter `mitigate_smt_rsb`를 켭니다. 예를 들면 `kvm.mitigate_smt_rsb=1`입니다.