GhostRace CPU vulnerability threatens all major architectures — IBM and VU Amsterdam researchers detail new cross-platform speculative execution attack

Graphic from AMD's "Software Techniques for Managing Speculation in AMD Processors", used as a reference point for Ghostrace and Spectre.
Graphic from AMD's "Software Techniques for Managing Speculation in AMD Processors", used as a reference point for Ghostrace and Spectre. (Image credit: AMD)

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.

Freelance News Writer
  • 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.

    It's like locking your front door while leaving your back door wide open.
    Reply
  • wbfox
    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.
    You are totally fine. As long as you don't use anything like javascript or wasm, etc... you are good to go.
    Reply
  • 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
    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.
    They exist and have been documented. There's also vulnerabilities that attack zip/rar and root level certs on anti viruses.
    Reply
  • bluvg
    Has anyone done benchmark tests on the total performance lost in recent years due to all the CPU vulnerability fixes?
    Reply
  • bit_user
    bluvg said:
    Has anyone done benchmark tests on the total performance lost in recent years due to all the CPU vulnerability fixes?
    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.
    Reply
  • bluvg
    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.
    Right, but has anyone actually benchmarked all of the vuln mitigations?
    Reply
  • bit_user
    bluvg said:
    Right, but has anyone actually benchmarked all of the vuln mitigations?
    I haven't seen this done, since the time I mentioned.
    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
    Reply
  • Amdlova
    If you want security you need change your cpu and motherboard every generation.
    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. :)
    Reply