Tag Archives: Spectre

Initial Benchmarks Of The Spectre “SWAPGS” Mitigation Performance Impact


Yesterday the SWAPGS vulnerability was made public as a new variant of Spectre V1 that affects all operating systems and is believed to affect only Intel CPUs. The SWAPGS discovery by Bitdefender was quietly mitigated by Microsoft for Windows 10 last month while yesterday the patches were posted for the mainline Linux kernel as the Grand Schemozzle. As soon as learning of this SWAPGS vulnerability and seeing the kernel code, I began running some preliminary performance tests to look at the impact of this latest CPU mitigation.

The kernel code added yesterday to mainline by Thomas Gleixner commented on the issue:

“The performance deterioration departement is not proud at all to present yet another set of speculation fences to mitigate the next chapter in the ‘what could possibly go wrong’ story.

The new vulnerability belongs to the Spectre class and affects GS based data accesses and has therefore been dubbed ‘Grand Schemozzle’ for secret communication purposes. It’s officially listed as CVE-2019-1125.”

Especially with that text, I was quite interested in seeing what the performance is looking like as a result of this latest kernel activity for tightening up the Intel CPU security. This morning I have results wrapped up on an Intel Core i9 9900K processor. SWAPGS or the “Grand Schemozzle” is believed to affect all Intel CPUs from at least Ivybridge through their latest products.

The Core i9 9900K processor was indeed reported as affected when running on the patched kernel. I fired off some benchmarks of the Linux 5.3 kernel code as of Sunday compared to the latest code as of overnight that’s been patched for SWAPGS and mitigated by default unless explicitly disabling Spectre V1 mitigations or all CPU vulnerability mitigations in general. Contrary to Red Hat’s report initially saying AMD CPUs are affected, the Linux kernel is not applying this SWAPGS mitigation to AMD hardware (AMD has also issued a statement that they believe they are unaffected by this new Spectre V1 variant).

Over the days ahead I’ll work on more SWAPGS benchmarks particularly on a generation or two older to see if the performance impact is any more noticeable. On the following pages are these initial results from the Core i9 9900K system running Ubuntu 19.04 with Linux 5.3 Git.


Benchmarking AMD FX vs. Intel Sandy/Ivy Bridge CPUs Following Spectre, Meltdown, L1TF, Zombieload


Now with MDS / Zombieload being public and seeing a 8~10% performance hit in the affected workloads as a result of the new mitigations to these Microarchitectural Data Sampling vulnerabilities, what’s the overall performance look like now if going back to the days of AMD FX Vishera and Intel Sandybridge/Ivybridge processors? If Spectre, Meltdown, L1TF/Foreshadow, and now Zombieload had come to light years ago would it have shaken that pivotal point in the industry? Here are benchmarks looking at the the performance today with and without the mitigations to the known CPU vulnerabilities to date.

As I’ve already delivered many benchmarks of these mitigations (including MDS/Zombieload) on newer CPUs, for this article we’re looking at older AMD FX CPUs with their relevant Spectre mitigations against Intel Sandybridge and Ivybridge with the Spectre/Meltdown/L1TF/MDS mitigations. Tests were done on Ubuntu 19.04 with the Linux 5.0 kernel while toggling the mitigation levels of off (no coverage) / auto (the default / out-of-the-box mitigations used on all major Linux distributions for the default protections) / auto,nosmt (the more restricted level that also disables SMT / Hyper Threading). The AMD CPUs were tested with off/auto as in the “auto,nosmt” mode it doesn’t disable any SMT as it doesn’t deem it insecure on AMD platforms.

The processors used for testing were the:

– Intel Core i3 2120

– Intel Core i5 2500K

– Intel Core i7 2700K

– Intel Core i7 3700K

– AMD FX-8320E

– AMD FX-8370E

– AMD FX-8370

Based on what I had available in a still working state and not running into any other issues (like motherboard problems preventing the FX-9590 from being tested) as well as time constraints. All of the systems were running with their latest BIOS, 2 x 4GB DDR3 system memory, and SATA 3.0 SSD storage (primarily the Samsung SSD 850). The ASRock Z68 Pro3 was the primary Intel Sandy/Ivy test platform while on the AMD side was the MSI 970 GAMING.

Ubuntu 19.04 x86_64 with the Linux 5.0.0-15-generic kernel was at play with all available Disco Dingo stable release updates. Via the Phoronix Test Suite a wide range of benchmarks were carried out focused on looking at the impact of the CPU vulnerability mitigations for these aging Intel and AMD desktop platforms.


OpenSUSE’s Spectre Mitigation Approach Is One Of The Reasons For Its Slower Performance


SUSE --

OpenSUSE defaults to IBRS for its Spectre Variant Two mitigations rather than the Retpolines approach and that is one of the reasons for the distribution’s slower out-of-the-box performance compared to other Linux distributions.

A Phoronix reader pointed out this opensuse-factory mailing list thread citing a “huge single-core performance loss” on a Lenovo laptop when using openSUSE. There’s a ~21% performance loss in single-threaded performance around the Spectre Variant Two mitigations, which itself isn’t surprising as we’ve shown time and time again about the performance costs of the Spectre/Meltdown mitigations.

OpenSUSE’s kernel is using IBRS (Indirect Branch Restricted Speculation) with the latest Intel CPU microcode images while most Linux distributions are relying upon Retpolines as return trampolines. The IBRS mitigation technique has the potential of incurring more of a performance loss than Retpolines, which has been known to incur a greater performance hit due to the more restricted speculation behavior when paired with the updated Intel CPU microcode.

Switching over to Retpolines for the workload in question restored the performance, per the mailing list discussion.

OpenSUSE users wanting to use that non-default approach can opt for it using the spectre_v2=retpoline,generic kernel command line parameter, which matches the behavior of most other Linux distributions’ kernels.

As for openSUSE changing their defaults, at least from the aforelinked mailing list discussion it doesn’t appear their kernel engineers have any interest in changing their Spectre mitigation default but are just blaming the poor performance on Intel as their problem.

Some have also suggested the openSUSE installer pick-up a toggle within its installer for informing users of security vs. performance preferences in better providing sane/informed defaults, but so far we haven’t seen any action taken to make that happen. It would make sense though considering some of openSUSE’s conservative defaults do have performance ramifications compared to most other Linux distributions, which we’ve shown in past benchmarks, albeit just written off by openSUSE as “mostly crap.”

Previously a barrier to Retpolines usage was needing the Retpolines compiler support, but that support has now been available for quite some time. There was also reported Retpolines issues with Skylake in the past, but those appear to have been resolved as well.


NXP PowerPC Processors Finally Being Mitigated Against Spectre V2 With Linux 4.21


SECURITY --

Nearly one year after the Spectre vulnerabilities were first published, Freescale/NXP PowerPC processors are being mitigated against Spectre Variant Two with the in-development Linux 4.21 kernel.

Queued for merging into Linux 4.21 is the Spectre V2 mitigation for these NXP PowerPC Book3E processors. Their approach is to flush the branch predictor whenever the privilege level has changed or kernel entry to protect user-space to user-space attacks and user-space attacks against the kernel. In the case of KVM virtualization, the branch predictor is flushed as well at each KVM entry.

For those that want to forego this mitigation to avoid the likely performance impact, the code does support a no_spectrev2 kernel command line parameter (the same as on x86-based platforms) that won’t enforce this frequent branch predictor flushing.

NXP developers working on this Spectre V2 mitigation hadn’t shared any of their expected performance costs of this mitigation.

The mitigation is landing as part of the PowerPC changes. That pull also has POWER DMA code changes, support for generating their system call tables from a text file, fixes to the transactional memory support, and other low-level changes.


Patches For The Better Spectre STIBP Approach Revised – Version 7 Under Review


LINUX KERNEL --

Version 7 of the task property based options to enable Spectre V2 userspace-userspace protection patches, a.k.a. the work offering improved / less regressing approach for STIBP, is now available for testing and code review.

Tim Chen of Intel sent out the seventh revision to these patches on Tuesday night. Besides the Spectre V2 app-to-app protection modes, these patches include the work for disabling STIBP (Single Thread Indirect Branch Predictors) when enhanced IBRS (Indirect Branch Restricted Speculation) is supported/used, and allowing for STIBP to be enabled manually and just by default for non-dumpable tasks.

The STIBP patches will no longer take the “big hammer” approach for cross-hyperthread Spectre Variant Two mitigation so the performance hit isn’t across the board but restricting it to non-dumpable tasks like OpenSSH rather than for every process as is currently done with Linux 4.20 Git and back-ported series like Linux 4.19.2+.

With the new V7 patches there is protection for SECCOMP tasks, bug fixes, updated the boot options to align with the other speculation mitigations, disabling the SMT code paths when irrelevant for the current system configuration, and other code changes. All the details can be found via this patch series.

While Linus Torvalds a few days ago criticized the current STIBP approach, he stopped short of calling for it to be reverted right away but is certainly wanting the default behavior to change, which will be by this patch series. However, until this patch series is ready for merging, Tim Chen is calling for the current STIBP code to be reverted. He noted, “Since Jiri’s patchset to always turn on STIBP has big performance impact, I think that it should be reverted from 4.20 and stable kernels for now, till this patchset to mitigate its performance impact can be merged with it.

Greg KH did release Linux 4.19.3 this morning and other stable point releases, but the STIBP code hasn’t been touched with today’s updates. Hopefully it won’t be much longer though until these cleaned up patches are mainlined as the current performance overhead is significant.