Still-Pending AMD PSF Control Patch To Be Retailored For KVM
Of all the great stuff for AMD in Linux 5.15, one of the patches still not having yet been mainlined is the control support around Predictive Store Forwarding (PSF) with Zen 3 processors. It's been six months since AMD published their security whitepaper around PSF while the Linux patch has yet to be mainlined while now it seems will be updated for a reduced focus on KVM usage.
It's been about six months already since AMD published their security analysis of Zen 3's PSF feature that could potentially lead to a side channel attack. Predictive Store Forwarding with the latest-generation Ryzen and EPYC processors allows for speculatively executing instructions based on what it thinks the result of the load will be and while the predictions should be largely accurate, there is the small possibility of incorrect CPU speculation. PSF speculation going awry would be similar to Spectre V4 / SSB.
The AMD analysis from March did note, "AMD believes that for most applications, the security risk of PSF is likely low and where isolation is required, techniques such as address space isolation are preferred over software sandboxing."
AMD did send out Linux kernel patch to optionally allow PSF to be disabled by itself or it's also disabled as part of the Spectre V4 mitigations. For over five months that kernel work has been public, it has undergone code review for possible mainline integration. The semantics of the PSF command-line control naming has resulted in some changes as well as ongoing discussion whether there should be an "auto" mode rather than just the on/off modes and defaulting to PSF enabled.
There doesn't appear to be much of an emphasis by AMD on getting the PSF control support merged quickly given the time it's been since the PSF whitepaper and the patch discussion only reigniting every few weeks or longer. Fortunately, the possibility of PSF being exploited in the real-world appears to remain very low and thus seemingly not a priority for getting the changed merged quickly and with no default change in behavior.
Most recently it's been suggested by upstream just doing away with their current PSF patch and provide updated guidance in the documentation. Since SSBD for Spectre V4 mitigation also disables PSF, interested parties would likely just go that route rather than adding extra kernel controls and complexity.
The latest messaging as of Friday is now that AMD will likely "revisit this later when it seems reasonable to add this in the kernel." A new PSF patch though is expected for at least controlling the PSF feature being exposed to KVM guests and that code is expected soon.
All indications are the the real-world threat around PSF is very low and haven't heard of any increased concern over the past half-year since the original security whitepaper was published. However, more broadly it's not very reassuring to see this kernel patch tossed around for a half-year and due to the lack of a concerted effort potentially just dropped at this stage. Intel has had more vulnerabilities to deal with and often of greater significance, but at least there they have been well organized to ensure that generally on the same day of any new public disclosures they already have kernel patches going into the mainline kernel right away with any new controls/mitigations. This is an ongoing area for AMD to improve upon with their Linux support and hopefully there will be that greater coordination by AMD engineers and the upstream kernel developers so any future issues can be patched more timely.
It's been about six months already since AMD published their security analysis of Zen 3's PSF feature that could potentially lead to a side channel attack. Predictive Store Forwarding with the latest-generation Ryzen and EPYC processors allows for speculatively executing instructions based on what it thinks the result of the load will be and while the predictions should be largely accurate, there is the small possibility of incorrect CPU speculation. PSF speculation going awry would be similar to Spectre V4 / SSB.
The AMD analysis from March did note, "AMD believes that for most applications, the security risk of PSF is likely low and where isolation is required, techniques such as address space isolation are preferred over software sandboxing."
AMD did send out Linux kernel patch to optionally allow PSF to be disabled by itself or it's also disabled as part of the Spectre V4 mitigations. For over five months that kernel work has been public, it has undergone code review for possible mainline integration. The semantics of the PSF command-line control naming has resulted in some changes as well as ongoing discussion whether there should be an "auto" mode rather than just the on/off modes and defaulting to PSF enabled.
There doesn't appear to be much of an emphasis by AMD on getting the PSF control support merged quickly given the time it's been since the PSF whitepaper and the patch discussion only reigniting every few weeks or longer. Fortunately, the possibility of PSF being exploited in the real-world appears to remain very low and thus seemingly not a priority for getting the changed merged quickly and with no default change in behavior.
Most recently it's been suggested by upstream just doing away with their current PSF patch and provide updated guidance in the documentation. Since SSBD for Spectre V4 mitigation also disables PSF, interested parties would likely just go that route rather than adding extra kernel controls and complexity.
The latest messaging as of Friday is now that AMD will likely "revisit this later when it seems reasonable to add this in the kernel." A new PSF patch though is expected for at least controlling the PSF feature being exposed to KVM guests and that code is expected soon.
All indications are the the real-world threat around PSF is very low and haven't heard of any increased concern over the past half-year since the original security whitepaper was published. However, more broadly it's not very reassuring to see this kernel patch tossed around for a half-year and due to the lack of a concerted effort potentially just dropped at this stage. Intel has had more vulnerabilities to deal with and often of greater significance, but at least there they have been well organized to ensure that generally on the same day of any new public disclosures they already have kernel patches going into the mainline kernel right away with any new controls/mitigations. This is an ongoing area for AMD to improve upon with their Linux support and hopefully there will be that greater coordination by AMD engineers and the upstream kernel developers so any future issues can be patched more timely.
Add A Comment