Comparison of AMD Zen 3 with Predictive Store Forwarding disabled

Last week, AMD published a security review of AMD Zen 3’s new Predictive Store Forwarding (PSF) feature. There, they acknowledged that there is a possibility that poor PSF functionality could lead to a side channel attack, although exposure in the real world is very low. In any case, they are allowing interested users to disable the predictive storage forwarding functionality, but what they did not comment on in that document was what performance overhead to expect when disabling PSF. So, my Easter weekend turned into AMD Zen 3 PSF benchmarking.

AMD is not recommending that end users disable Zen 3’s Protective Store Forwarding functionality, but rather be proactive in their public safety analysis and ensure that their customers are informed about their behavior and how to disable it if they are interested. The impact of poor PSF speculation would be similar to that of Specter Variant Four / Speculative storage bypass. AMD’s PSF security review noted, “customers with software that implements sandboxing and are concerned about PSF behavior on AMD Zen3 processors may choose to disable PSF functionality.

PSF is disabled with Zen 3 CPUs if Speculative Storage Bypass Disabling (SSBD) mitigation is present or optionally just disabled by means of a different bit. The AMD white paper says that they are publishing Linux patches to allow them to easily disable PSF if desired, but as of yet I have not seen these public patches anywhere. Presumably, they will succeed in the next few days to allow for the convenient “nopsfd” kernel option. But for initial testing purposes this weekend, I just built a kernel that defines MSR 48h Bit 7 to disable this predictive storage forwarding feature. By default, Linux does not do mitigation with SSBD, unless you choose to do so through the prctl or SECCOMP interface.

Not knowing what to expect this weekend with a lack of details on the performance implications of deactivating Predictive Store Forwarding, I ran dozens of benchmarks on some different systems from the AMD Ryzen 5000 and EPYC 7003 series with the standard kernel and the same kernel / configuration, but with PSF disabled via bit 7.

Among the various systems and the wide variety of workloads tested and with the Phoronix Test Suite automatically running each test several times, etc., in the end, the results with the PSF deactivation were of minimal difference. At most, some workloads had an impact of close to 1% on the range of multiple runs and the various systems, but overall it was difficult to find any statistically significant difference.

For example, with the Ryzen 7 5800X box it was this set of results from more than 100 tests. With the geometric average of all of these results there was less than half a percent of performance loss when disabling this new Zen 3 feature. The other result files are even more boring than that.

To summarize the story, although AMD does not recommend to its customers in general to disable Predictive Store Forwarding, if you decide to disable it in the name of increased security, there is likely to be no significant difference in performance. I am still running some larger server workloads, but with everything I saw today and yesterday on several Zen 3 systems, disabling PSF is not having any major impact. Fortunately, nothing as scary as some of the earlier speculative x86_64 mitigations we saw in recent years – just a few days ago, actually looking at the costs of Spectrum mitigation still being carried by Intel’s Rocket Lake, among many other examples. and references over the past three years.

For those who appreciate the rapid return of the AMD Zen 3 PSF benchmarkng this Easter weekend, consider joining Phoronix Premium or perhaps a tip. At the very least, please, no use of ad blockers; your support makes it possible to be able to benchmark every day of the year.

If you liked this article, consider joining Phoronix Premium to view this site without ads, multi-page articles on a single page and other benefits. PayPal tips are also graciously accepted. Thank you for your support.

.Source