Skip to content

Commit fb467c7

Browse files
kelsey-steelekelsey-steele
committed
Merge tag 'rolling-lts/wsl/5.15.133.1' into linux-msft-wsl-5.15.y
Linux rolling-lts/wsl/5.15.133.1 Signed-off-by: Kelsey Steele <[email protected]>
2 parents c2aaae2 + 866ebb7 commit fb467c7

File tree

1,325 files changed

+15914
-10096
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

1,325 files changed

+15914
-10096
lines changed

‎Documentation/ABI/testing/sysfs-devices-system-cpu‎

Lines changed: 7 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -511,17 +511,18 @@ Description: information about CPUs heterogeneity.
511511
cpu_capacity: capacity of cpu#.
512512

513513
What: /sys/devices/system/cpu/vulnerabilities
514+
/sys/devices/system/cpu/vulnerabilities/gather_data_sampling
515+
/sys/devices/system/cpu/vulnerabilities/itlb_multihit
516+
/sys/devices/system/cpu/vulnerabilities/l1tf
517+
/sys/devices/system/cpu/vulnerabilities/mds
514518
/sys/devices/system/cpu/vulnerabilities/meltdown
519+
/sys/devices/system/cpu/vulnerabilities/mmio_stale_data
520+
/sys/devices/system/cpu/vulnerabilities/retbleed
521+
/sys/devices/system/cpu/vulnerabilities/spec_store_bypass
515522
/sys/devices/system/cpu/vulnerabilities/spectre_v1
516523
/sys/devices/system/cpu/vulnerabilities/spectre_v2
517-
/sys/devices/system/cpu/vulnerabilities/spec_store_bypass
518-
/sys/devices/system/cpu/vulnerabilities/l1tf
519-
/sys/devices/system/cpu/vulnerabilities/mds
520524
/sys/devices/system/cpu/vulnerabilities/srbds
521525
/sys/devices/system/cpu/vulnerabilities/tsx_async_abort
522-
/sys/devices/system/cpu/vulnerabilities/itlb_multihit
523-
/sys/devices/system/cpu/vulnerabilities/mmio_stale_data
524-
/sys/devices/system/cpu/vulnerabilities/retbleed
525526
Date: January 2018
526527
Contact: Linux kernel mailing list <[email protected]>
527528
Description: Information about CPU vulnerabilities

‎Documentation/admin-guide/hw-vuln/gather_data_sampling.rst‎

Lines changed: 109 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,109 @@
1+
.. SPDX-License-Identifier: GPL-2.0
2+
3+
GDS - Gather Data Sampling
4+
==========================
5+
6+
Gather Data Sampling is a hardware vulnerability which allows unprivileged
7+
speculative access to data which was previously stored in vector registers.
8+
9+
Problem
10+
-------
11+
When a gather instruction performs loads from memory, different data elements
12+
are merged into the destination vector register. However, when a gather
13+
instruction that is transiently executed encounters a fault, stale data from
14+
architectural or internal vector registers may get transiently forwarded to the
15+
destination vector register instead. This will allow a malicious attacker to
16+
infer stale data using typical side channel techniques like cache timing
17+
attacks. GDS is a purely sampling-based attack.
18+
19+
The attacker uses gather instructions to infer the stale vector register data.
20+
The victim does not need to do anything special other than use the vector
21+
registers. The victim does not need to use gather instructions to be
22+
vulnerable.
23+
24+
Because the buffers are shared between Hyper-Threads cross Hyper-Thread attacks
25+
are possible.
26+
27+
Attack scenarios
28+
----------------
29+
Without mitigation, GDS can infer stale data across virtually all
30+
permission boundaries:
31+
32+
Non-enclaves can infer SGX enclave data
33+
Userspace can infer kernel data
34+
Guests can infer data from hosts
35+
Guest can infer guest from other guests
36+
Users can infer data from other users
37+
38+
Because of this, it is important to ensure that the mitigation stays enabled in
39+
lower-privilege contexts like guests and when running outside SGX enclaves.
40+
41+
The hardware enforces the mitigation for SGX. Likewise, VMMs should ensure
42+
that guests are not allowed to disable the GDS mitigation. If a host erred and
43+
allowed this, a guest could theoretically disable GDS mitigation, mount an
44+
attack, and re-enable it.
45+
46+
Mitigation mechanism
47+
--------------------
48+
This issue is mitigated in microcode. The microcode defines the following new
49+
bits:
50+
51+
================================ === ============================
52+
IA32_ARCH_CAPABILITIES[GDS_CTRL] R/O Enumerates GDS vulnerability
53+
and mitigation support.
54+
IA32_ARCH_CAPABILITIES[GDS_NO] R/O Processor is not vulnerable.
55+
IA32_MCU_OPT_CTRL[GDS_MITG_DIS] R/W Disables the mitigation
56+
0 by default.
57+
IA32_MCU_OPT_CTRL[GDS_MITG_LOCK] R/W Locks GDS_MITG_DIS=0. Writes
58+
to GDS_MITG_DIS are ignored
59+
Can't be cleared once set.
60+
================================ === ============================
61+
62+
GDS can also be mitigated on systems that don't have updated microcode by
63+
disabling AVX. This can be done by setting gather_data_sampling="force" or
64+
"clearcpuid=avx" on the kernel command-line.
65+
66+
If used, these options will disable AVX use by turning off XSAVE YMM support.
67+
However, the processor will still enumerate AVX support. Userspace that
68+
does not follow proper AVX enumeration to check both AVX *and* XSAVE YMM
69+
support will break.
70+
71+
Mitigation control on the kernel command line
72+
---------------------------------------------
73+
The mitigation can be disabled by setting "gather_data_sampling=off" or
74+
"mitigations=off" on the kernel command line. Not specifying either will default
75+
to the mitigation being enabled. Specifying "gather_data_sampling=force" will
76+
use the microcode mitigation when available or disable AVX on affected systems
77+
where the microcode hasn't been updated to include the mitigation.
78+
79+
GDS System Information
80+
------------------------
81+
The kernel provides vulnerability status information through sysfs. For
82+
GDS this can be accessed by the following sysfs file:
83+
84+
/sys/devices/system/cpu/vulnerabilities/gather_data_sampling
85+
86+
The possible values contained in this file are:
87+
88+
============================== =============================================
89+
Not affected Processor not vulnerable.
90+
Vulnerable Processor vulnerable and mitigation disabled.
91+
Vulnerable: No microcode Processor vulnerable and microcode is missing
92+
mitigation.
93+
Mitigation: AVX disabled,
94+
no microcode Processor is vulnerable and microcode is missing
95+
mitigation. AVX disabled as mitigation.
96+
Mitigation: Microcode Processor is vulnerable and mitigation is in
97+
effect.
98+
Mitigation: Microcode (locked) Processor is vulnerable and mitigation is in
99+
effect and cannot be disabled.
100+
Unknown: Dependent on
101+
hypervisor status Running on a virtual guest processor that is
102+
affected but with no way to know if host
103+
processor is mitigated or vulnerable.
104+
============================== =============================================
105+
106+
GDS Default mitigation
107+
----------------------
108+
The updated microcode will enable the mitigation by default. The kernel's
109+
default action is to leave the mitigation enabled.

‎Documentation/admin-guide/hw-vuln/index.rst‎

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -19,3 +19,5 @@ are configurable at compile, boot or run time.
1919
l1d_flush.rst
2020
processor_mmio_stale_data.rst
2121
cross-thread-rsb.rst
22+
gather_data_sampling.rst
23+
srso

‎Documentation/admin-guide/hw-vuln/srso.rst‎

Lines changed: 133 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,133 @@
1+
.. SPDX-License-Identifier: GPL-2.0
2+
3+
Speculative Return Stack Overflow (SRSO)
4+
========================================
5+
6+
This is a mitigation for the speculative return stack overflow (SRSO)
7+
vulnerability found on AMD processors. The mechanism is by now the well
8+
known scenario of poisoning CPU functional units - the Branch Target
9+
Buffer (BTB) and Return Address Predictor (RAP) in this case - and then
10+
tricking the elevated privilege domain (the kernel) into leaking
11+
sensitive data.
12+
13+
AMD CPUs predict RET instructions using a Return Address Predictor (aka
14+
Return Address Stack/Return Stack Buffer). In some cases, a non-architectural
15+
CALL instruction (i.e., an instruction predicted to be a CALL but is
16+
not actually a CALL) can create an entry in the RAP which may be used
17+
to predict the target of a subsequent RET instruction.
18+
19+
The specific circumstances that lead to this varies by microarchitecture
20+
but the concern is that an attacker can mis-train the CPU BTB to predict
21+
non-architectural CALL instructions in kernel space and use this to
22+
control the speculative target of a subsequent kernel RET, potentially
23+
leading to information disclosure via a speculative side-channel.
24+
25+
The issue is tracked under CVE-2023-20569.
26+
27+
Affected processors
28+
-------------------
29+
30+
AMD Zen, generations 1-4. That is, all families 0x17 and 0x19. Older
31+
processors have not been investigated.
32+
33+
System information and options
34+
------------------------------
35+
36+
First of all, it is required that the latest microcode be loaded for
37+
mitigations to be effective.
38+
39+
The sysfs file showing SRSO mitigation status is:
40+
41+
/sys/devices/system/cpu/vulnerabilities/spec_rstack_overflow
42+
43+
The possible values in this file are:
44+
45+
- 'Not affected' The processor is not vulnerable
46+
47+
- 'Vulnerable: no microcode' The processor is vulnerable, no
48+
microcode extending IBPB functionality
49+
to address the vulnerability has been
50+
applied.
51+
52+
- 'Mitigation: microcode' Extended IBPB functionality microcode
53+
patch has been applied. It does not
54+
address User->Kernel and Guest->Host
55+
transitions protection but it does
56+
address User->User and VM->VM attack
57+
vectors.
58+
59+
(spec_rstack_overflow=microcode)
60+
61+
- 'Mitigation: safe RET' Software-only mitigation. It complements
62+
the extended IBPB microcode patch
63+
functionality by addressing User->Kernel
64+
and Guest->Host transitions protection.
65+
66+
Selected by default or by
67+
spec_rstack_overflow=safe-ret
68+
69+
- 'Mitigation: IBPB' Similar protection as "safe RET" above
70+
but employs an IBPB barrier on privilege
71+
domain crossings (User->Kernel,
72+
Guest->Host).
73+
74+
(spec_rstack_overflow=ibpb)
75+
76+
- 'Mitigation: IBPB on VMEXIT' Mitigation addressing the cloud provider
77+
scenario - the Guest->Host transitions
78+
only.
79+
80+
(spec_rstack_overflow=ibpb-vmexit)
81+
82+
In order to exploit vulnerability, an attacker needs to:
83+
84+
- gain local access on the machine
85+
86+
- break kASLR
87+
88+
- find gadgets in the running kernel in order to use them in the exploit
89+
90+
- potentially create and pin an additional workload on the sibling
91+
thread, depending on the microarchitecture (not necessary on fam 0x19)
92+
93+
- run the exploit
94+
95+
Considering the performance implications of each mitigation type, the
96+
default one is 'Mitigation: safe RET' which should take care of most
97+
attack vectors, including the local User->Kernel one.
98+
99+
As always, the user is advised to keep her/his system up-to-date by
100+
applying software updates regularly.
101+
102+
The default setting will be reevaluated when needed and especially when
103+
new attack vectors appear.
104+
105+
As one can surmise, 'Mitigation: safe RET' does come at the cost of some
106+
performance depending on the workload. If one trusts her/his userspace
107+
and does not want to suffer the performance impact, one can always
108+
disable the mitigation with spec_rstack_overflow=off.
109+
110+
Similarly, 'Mitigation: IBPB' is another full mitigation type employing
111+
an indrect branch prediction barrier after having applied the required
112+
microcode patch for one's system. This mitigation comes also at
113+
a performance cost.
114+
115+
Mitigation: safe RET
116+
--------------------
117+
118+
The mitigation works by ensuring all RET instructions speculate to
119+
a controlled location, similar to how speculation is controlled in the
120+
retpoline sequence. To accomplish this, the __x86_return_thunk forces
121+
the CPU to mispredict every function return using a 'safe return'
122+
sequence.
123+
124+
To ensure the safety of this mitigation, the kernel must ensure that the
125+
safe return sequence is itself free from attacker interference. In Zen3
126+
and Zen4, this is accomplished by creating a BTB alias between the
127+
untraining function srso_alias_untrain_ret() and the safe return
128+
function srso_alias_safe_ret() which results in evicting a potentially
129+
poisoned BTB entry and using that safe one for all function returns.
130+
131+
In older Zen1 and Zen2, this is accomplished using a reinterpretation
132+
technique similar to Retbleed one: srso_untrain_ret() and
133+
srso_safe_ret().

‎Documentation/admin-guide/kernel-parameters.txt‎

Lines changed: 42 additions & 14 deletions
Original file line numberDiff line numberDiff line change
@@ -1501,6 +1501,26 @@
15011501
Format: off | on
15021502
default: on
15031503

1504+
gather_data_sampling=
1505+
[X86,INTEL] Control the Gather Data Sampling (GDS)
1506+
mitigation.
1507+
1508+
Gather Data Sampling is a hardware vulnerability which
1509+
allows unprivileged speculative access to data which was
1510+
previously stored in vector registers.
1511+
1512+
This issue is mitigated by default in updated microcode.
1513+
The mitigation may have a performance impact but can be
1514+
disabled. On systems without the microcode mitigation
1515+
disabling AVX serves as a mitigation.
1516+
1517+
force: Disable AVX to mitigate systems without
1518+
microcode mitigation. No effect if the microcode
1519+
mitigation is present. Known to cause crashes in
1520+
userspace with buggy AVX enumeration.
1521+
1522+
off: Disable GDS mitigation.
1523+
15041524
gcov_persist= [GCOV] When non-zero (default), profiling data for
15051525
kernel modules is saved and remains accessible via
15061526
debugfs, even when the module is unloaded/reloaded.
@@ -3034,22 +3054,23 @@
30343054
Disable all optional CPU mitigations. This
30353055
improves system performance, but it may also
30363056
expose users to several CPU vulnerabilities.
3037-
Equivalent to: nopti [X86,PPC]
3057+
Equivalent to: gather_data_sampling=off [X86]
30383058
kpti=0 [ARM64]
3039-
nospectre_v1 [X86,PPC]
3040-
nobp=0 [S390]
3041-
nospectre_v2 [X86,PPC,S390,ARM64]
3042-
spectre_v2_user=off [X86]
3043-
spec_store_bypass_disable=off [X86,PPC]
3044-
ssbd=force-off [ARM64]
3059+
kvm.nx_huge_pages=off [X86]
30453060
l1tf=off [X86]
30463061
mds=off [X86]
3047-
tsx_async_abort=off [X86]
3048-
kvm.nx_huge_pages=off [X86]
3062+
mmio_stale_data=off [X86]
30493063
no_entry_flush [PPC]
30503064
no_uaccess_flush [PPC]
3051-
mmio_stale_data=off [X86]
3065+
nobp=0 [S390]
3066+
nopti [X86,PPC]
3067+
nospectre_v1 [X86,PPC]
3068+
nospectre_v2 [X86,PPC,S390,ARM64]
30523069
retbleed=off [X86]
3070+
spec_store_bypass_disable=off [X86,PPC]
3071+
spectre_v2_user=off [X86]
3072+
ssbd=force-off [ARM64]
3073+
tsx_async_abort=off [X86]
30533074

30543075
Exceptions:
30553076
This does not have any effect on
@@ -5429,6 +5450,17 @@
54295450
Not specifying this option is equivalent to
54305451
spectre_v2_user=auto.
54315452

5453+
spec_rstack_overflow=
5454+
[X86] Control RAS overflow mitigation on AMD Zen CPUs
5455+
5456+
off - Disable mitigation
5457+
microcode - Enable microcode mitigation only
5458+
safe-ret - Enable sw-only safe RET mitigation (default)
5459+
ibpb - Enable mitigation by issuing IBPB on
5460+
kernel entry
5461+
ibpb-vmexit - Issue IBPB only on VMEXIT
5462+
(cloud-specific mitigation)
5463+
54325464
spec_store_bypass_disable=
54335465
[HW] Control Speculative Store Bypass (SSB) Disable mitigation
54345466
(Speculative Store Bypass vulnerability)
@@ -5738,10 +5770,6 @@
57385770
-1: disable all critical trip points in all thermal zones
57395771
<degrees C>: override all critical trip points
57405772

5741-
thermal.nocrt= [HW,ACPI]
5742-
Set to disable actions on ACPI thermal zone
5743-
critical and hot trip points.
5744-
57455773
thermal.off= [HW,ACPI]
57465774
1: disable ACPI thermal control
57475775

0 commit comments

Comments
 (0)