GhostRace CPU vulnerability threatens all major architectures — IBM and VU Amsterdam researchers detail new cross-platform speculative execution attack
Speculative execution exploits are used against modern CPUs to access passwords and other confidential data.
On March 12, researchers from VUSec and IBM made a new form of speculative execution attack publicly known on Twitter, linking to a corresponding GhostRace disclosure paper hosted by VUSec. We'll be discussing the full GhostRace disclosure document and its attached documentation in more detail below, but first, let's take some time to clarify what a "speculative execution attack" even is.
If you remember the scourge of Meltdown and Spectre, back in 2016, this is very much in the same category of major CPU security exploits. Spectre V1 was explicitly a speculative execution attack, even. Speculative execution in and of itself isn't a bad thing— it's actually a core function of modern CPUs, which allows CPU threads to more effectively share resources.
The issue is, that speculative execution can also result in "race conditions", where separate threads attempting to access shared resources create major security vulnerabilities by doing so in a poorly-synchronized matter. This exploit is focused on taking advantage of those scenarios, so it's appropriately named GhostRace.
Before making GhostRace public, the researchers informed major hardware vendors and the Linux kernel of the issue (in late 2023), since GhostRace applies to all major OSes and CPUs, even Arm. The notice given should hopefully have given vendors the time they needed to develop their fixes and workarounds, however, the researchers also included some tips for mitigating the issue in the public document. An early fix attempt by the Linux kernel seemed promising, but experiments done by the researchers proved the fix didn't completely cover the vulnerability.
For now, it seems Linux kernel devs are primarily concerned with performance, and don't want to risk majorly crippling it with a rushed fix. We read that the proposed mitigation for Linux provided in the original documentation is tested as only having a roughly ~5% performance overhead in LMBench. No patching performance penalty is ever welcome, but perhaps a patiently developed fix can do better.
No mitigations are provided in the document for other platforms. However, AMD points out that existing Spectre v1 mitigations should still apply to potential GhostRace exploits— and since vendors have already had to tackle that, it should only be a matter of time. AMD has acknowledged the issue, according to the public disclosure paper.
Stay On the Cutting Edge: Get the Tom's Hardware Newsletter
Get Tom's Hardware's best news and in-depth reviews, straight to your inbox.
Christopher Harper has been a successful freelance tech writer specializing in PC hardware and gaming since 2015, and ghostwrote for various B2B clients in High School before that. Outside of work, Christopher is best known to friends and rivals as an active competitive player in various eSports (particularly fighting games and arena shooters) and a purveyor of music ranging from Jimi Hendrix to Killer Mike to the Sonic Adventure 2 soundtrack.
-
RichardtST Is there an easy way to turn off all these performance-killing fixes? I am the only one on my computer. No one else. If the hacker has enough control to squeak this information out of my CPU, then they already have complete control of the machine anyway. These kinds of bugs are only relevant for large servers with multiple users or anything up in the cloud. Leave my home computers out of it. I don't need this. I want to turn it (and all the other covert channel & speculative execution bugs) off.Reply -
vanadiel007 There will always be a vulnerability when using CPU's. But what is interesting is that I never heard of a GPU vulnerability.Reply
It's like locking your front door while leaving your back door wide open. -
wbfox
You are totally fine. As long as you don't use anything like javascript or wasm, etc... you are good to go.RichardtST said:Is there an easy way to turn off all these performance-killing fixes? I am the only one on my computer. No one else. If the hacker has enough control to squeak this information out of my CPU, then they already have complete control of the machine anyway. These kinds of bugs are only relevant for large servers with multiple users or anything up in the cloud. Leave my home computers out of it. I don't need this. I want to turn it (and all the other covert channel & speculative execution bugs) off. -
Vanderlindemedia Really, it's not affecting consumers but in a shared (cloud) space it's a big issue. Fixes that cut off 5% of it's performance can run into the hundreds of thousands if you think you have a full rack stacked with servers.Reply -
digitalgriffin
They exist and have been documented. There's also vulnerabilities that attack zip/rar and root level certs on anti viruses.vanadiel007 said:There will always be a vulnerability when using CPU's. But what is interesting is that I never heard of a GPU vulnerability.
It's like locking your front door while leaving your back door wide open. -
bluvg Has anyone done benchmark tests on the total performance lost in recent years due to all the CPU vulnerability fixes?Reply -
bit_user
In the early days of Zen 4 and Golden Cove, they actually showed slightly worse performance with all mitigations disabled. At the time, people wondered whether that's because those CPUs' branch predictors were optimized for the mitigated code paths.bluvg said:Has anyone done benchmark tests on the total performance lost in recent years due to all the CPU vulnerability fixes?
Of course, another aspect is that OS kernels know which CPU models need which mitigations, and tend to try not to enable the unnecessary ones for your CPU. So, this would concern only the subset of mitigations which cannot easily be switched on/off at runtime.
With the vulnerabilities discovered since then, I'd expect the net effect to again be worse, with mitigations enabled. Particularly in cases like Intel's AVX2 Gather bug, if you're running software that uses heavy AVX2. -
bluvg
Right, but has anyone actually benchmarked all of the vuln mitigations?bit_user said:In the early days of Zen 4 and Golden Cove, they actually showed slightly worse performance with all mitigations disabled. At the time, people wondered whether that's because those CPUs' branch predictors were optimized for the mitigated code paths.
Of course, another aspect is that OS kernels know which CPU models need which mitigations, and tend to try not to enable the unnecessary ones for your CPU. So, this would concern only the subset of mitigations which cannot easily be switched on/off at runtime.
With the vulnerabilities discovered since then, I'd expect the net effect to again be worse, with mitigations enabled. Particularly in cases like Intel's AVX2 Gather bug, if you're running software that uses heavy AVX2. -
bit_user
I haven't seen this done, since the time I mentioned.bluvg said:Right, but has anyone actually benchmarked all of the vuln mitigations?
https://www.phoronix.com/news/AMD-Zen-4-Mitigations-Off https://www.phoronix.com/review/amd-zen4-spectrev2 https://www.phoronix.com/review/raptor-lake-mitigations -
Amdlova If you want security you need change your cpu and motherboard every generation.Reply
When you know the bleed you are in another cycle.
Intel and amd sell for years cpus with breeches and don't and won't tell anyone. :)