AMD Posts New Linux Mitigation Handling For SRSO/Inception
([AMD] 6 Hours Ago
Speculative Return Stack Overflow)
- Reference: 0001503883
- News link: https://www.phoronix.com/news/AMD-New-SRSO-Inception-Linux
- Source link:
AMD Linux engineer Borislav Petkov kicked off the new week by volleying a patch for adjusting the Speculative Return Stack Overflow (SRSO, a.k.a. "Inception") vulnerability mitigation handling for capabilities to be found with affected processors running on newer CPU microcode.
SRSO/Inception as a reminder was [1]made public in August 2023 as a vulnerability with AMD CPUs from Zen 1 to Zen 4. Per the [2]kernel.org documentation as a refresher:
"AMD CPUs predict RET instructions using a Return Address Predictor (aka Return Address Stack/Return Stack Buffer). In some cases, a non-architectural CALL instruction (i.e., an instruction predicted to be a CALL but is not actually a CALL) can create an entry in the RAP which may be used to predict the target of a subsequent RET instruction.
The specific circumstances that lead to this varies by microarchitecture but the concern is that an attacker can mis-train the CPU BTB to predict non-architectural CALL instructions in kernel space and use this to control the speculative target of a subsequent kernel RET, potentially leading to information disclosure via a speculative side-channel."
While [3]AMD Zen 5 on Linux has been reporting "not affected" to the SRSO/Inception vulnerability today's kernel patch may help better control the SRSO mitigation for prior Ryzen and EPYC CPUs. The patch out today is around two new bits of "SRSO_USER_KERNEL_NO" for indicating the CPU is not subject to SRSO across user/kernel boundaries and "SRSO_MSR_FIX" for indicating that software can use the BpSpecReduce path for mitigating SRSO.
The patch from Petkov explains:
"If the machine has:
CPUID Fn8000_0021_EAX[30] (SRSO_USER_KERNEL_NO) -- If this bit is 1, it indicates the CPU is not subject to the SRSO vulnerability across user/kernel boundaries.
have it fall back to IBPB on VMEXIT only, in the case it is going to run VMs:
Speculative Return Stack Overflow: CPU user/kernel transitions protected, falling back to IBPB-on-VMEXIT Speculative Return Stack Overflow: Mitigation: IBPB on VMEXIT only
Then, upon KVM module load and in case the machine has
CPUID Fn8000_0021_EAX[31] (SRSO_MSR_FIX). If this bit is 1, it indicates that software may use MSR BP_CFG[BpSpecReduce] to mitigate SRSO.
enable this BpSpecReduce bit to mitigate SRSO across guest/host boundaries."
Both SRSO_USER_KERNEL_NO and SRSO_MSR_FIX are mentioned in [4]this February 2024 whitepaper on a technical update around SRSO. It's not clear though why it has taken one and a half years for the Linux kernel to now be adapted for the "new" SRSO_MSR_FIX and SRSO_USER_KERNEL_NO capabilities. In any event, [5]this kernel patch is now out for review on the Linux kernel mailing list to adapt the SRSO mitigation.
[1] https://www.phoronix.com/news/AMD-Inception-Cleanup
[2] https://docs.kernel.org/admin-guide/hw-vuln/srso.html
[3] https://www.phoronix.com/review/amd-zen5-mitigations-off
[4] https://www.amd.com/content/dam/amd/en/documents/corporate/cr/speculative-return-stack-overflow-whitepaper.pdf
[5] https://lore.kernel.org/lkml/20241104101543.31885-1-bp@kernel.org/
SRSO/Inception as a reminder was [1]made public in August 2023 as a vulnerability with AMD CPUs from Zen 1 to Zen 4. Per the [2]kernel.org documentation as a refresher:
"AMD CPUs predict RET instructions using a Return Address Predictor (aka Return Address Stack/Return Stack Buffer). In some cases, a non-architectural CALL instruction (i.e., an instruction predicted to be a CALL but is not actually a CALL) can create an entry in the RAP which may be used to predict the target of a subsequent RET instruction.
The specific circumstances that lead to this varies by microarchitecture but the concern is that an attacker can mis-train the CPU BTB to predict non-architectural CALL instructions in kernel space and use this to control the speculative target of a subsequent kernel RET, potentially leading to information disclosure via a speculative side-channel."
While [3]AMD Zen 5 on Linux has been reporting "not affected" to the SRSO/Inception vulnerability today's kernel patch may help better control the SRSO mitigation for prior Ryzen and EPYC CPUs. The patch out today is around two new bits of "SRSO_USER_KERNEL_NO" for indicating the CPU is not subject to SRSO across user/kernel boundaries and "SRSO_MSR_FIX" for indicating that software can use the BpSpecReduce path for mitigating SRSO.
The patch from Petkov explains:
"If the machine has:
CPUID Fn8000_0021_EAX[30] (SRSO_USER_KERNEL_NO) -- If this bit is 1, it indicates the CPU is not subject to the SRSO vulnerability across user/kernel boundaries.
have it fall back to IBPB on VMEXIT only, in the case it is going to run VMs:
Speculative Return Stack Overflow: CPU user/kernel transitions protected, falling back to IBPB-on-VMEXIT Speculative Return Stack Overflow: Mitigation: IBPB on VMEXIT only
Then, upon KVM module load and in case the machine has
CPUID Fn8000_0021_EAX[31] (SRSO_MSR_FIX). If this bit is 1, it indicates that software may use MSR BP_CFG[BpSpecReduce] to mitigate SRSO.
enable this BpSpecReduce bit to mitigate SRSO across guest/host boundaries."
Both SRSO_USER_KERNEL_NO and SRSO_MSR_FIX are mentioned in [4]this February 2024 whitepaper on a technical update around SRSO. It's not clear though why it has taken one and a half years for the Linux kernel to now be adapted for the "new" SRSO_MSR_FIX and SRSO_USER_KERNEL_NO capabilities. In any event, [5]this kernel patch is now out for review on the Linux kernel mailing list to adapt the SRSO mitigation.
[1] https://www.phoronix.com/news/AMD-Inception-Cleanup
[2] https://docs.kernel.org/admin-guide/hw-vuln/srso.html
[3] https://www.phoronix.com/review/amd-zen5-mitigations-off
[4] https://www.amd.com/content/dam/amd/en/documents/corporate/cr/speculative-return-stack-overflow-whitepaper.pdf
[5] https://lore.kernel.org/lkml/20241104101543.31885-1-bp@kernel.org/
phoronix