AMD Posts New Linux Mitigation Handling For SRSO/Inception
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 made public in August 2023 as a vulnerability with AMD CPUs from Zen 1 to Zen 4. Per the kernel.org documentation as a refresher:
While 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:
Both SRSO_USER_KERNEL_NO and SRSO_MSR_FIX are mentioned in 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, this kernel patch is now out for review on the Linux kernel mailing list to adapt the SRSO mitigation.
SRSO/Inception as a reminder was made public in August 2023 as a vulnerability with AMD CPUs from Zen 1 to Zen 4. Per the 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 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 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, this kernel patch is now out for review on the Linux kernel mailing list to adapt the SRSO mitigation.
Add A Comment