New Vulnerability Affects All AMD Zen CPUs: Threading May Need to Be Disabled

News
By
published

Side-channel SQUIP vulnerability affects all SMT-enabled Zen CPUs.

AMD
(Image credit: AMD)

Contemporary superscalar microprocessors with out-of-order execution use a number of ways to boost their performance. Simultaneous multi-threading (executing more than one threads of code on a CPU core) is one of the most efficient ways to improve processor performance. 

But AMD's implementation of SMT appears to be vulnerable to the so-called SQUIP side-channel attack that can reveal a 4096-bit RSA key fairly quickly.

All of AMD's Zen microarchitectures have separate scheduler queues per execution unit (so do Apple's M1-series CPUs). Each of these schedulers maintains separate queues from where the μops are issued for the corresponding execution units. AMD’s scheduler with SMT enabled introduces interferences across workloads, which opens doors to observe scheduler queue contention via performance counters and unserialized timer reads across sibling threads on the same core. Such priming and probing allows it to perform a side-channel attack on scheduler ques. The researchers call the method Scheduler Queue Usage (i.e., occupancy) via Interference Probing, or SQUIP. 

The vulnerability affects all of AMD's existing Ryzen processors with Zen 1/2/3 microarchitectures. To exploit the weakness and get access to data processed by the same CPU core, perpetrators need to run malicious code on that CPU core first, which is not particularly easy. Meanwhile, complete mitigation of SQUIP might require disabling SMT technology on all of AMD's existing Zen-based processors, which will seriously hurt their performance. 

"An attacker running on the same host and CPU core as you, could spy on which types of instructions you are executing due to the split-scheduler design on AMD CPUs," explained Daniel Gruss, a computer researcher from Graz University of Technology, in a conversation with The Register. "Apple's M1 (probably also M2) follows the same design but is not affected yet as they haven't introduced SMT in their CPUs yet." 

AMD reportedly confirmed the problem — currently called AMD-SB-1039: Execution Unit Scheduler Contention Side-Channel vulnerability on AMD Processors — and said that the company considers it a 'medium severity' threat. 

"AMD recommends software developers employ existing best practices including constant-time algorithms and avoiding secret-dependent control flows where appropriate to help mitigate this potential vulnerability," AMD's mitigation reads.

Anton Shilov
Anton Shilov
Contributing Writer

Anton Shilov is a contributing writer at Tom’s Hardware. Over the past couple of decades, he has covered everything from CPUs and GPUs to supercomputers and from modern process technologies and latest fab tools to high-tech industry trends.

17 Comments Comment from the forums
  • johnrock2
    Might need to disable SMT to prevent an attack that requires an attacker to first run code on your PC in order to take advantage of the attack vector...

    Why? As far as I can tell this is another one of those "you have to be physically present at the PC" attacks or "the user has to be dumb enough to run untrusted software" schemes. Disabling SMT over something like this is like removing the turbo on your car's engine because it's possible that somebody could break into you car and rig it to behave in a way not expected. You don't cripple your equipment to spite the enemy, you fix your security.

    It's incredibly narrow sighted to strip out one of CPU technology's greatest efficiency and computational improvements to close a single hard to use attack vector. Instead You put out an advisory for those using such CPUs to process sensitive information so they can make a decision for themselves. Everyone else will get a microcode patch or an os update to fix the issue at a latter date.

    I don't get all the fear mongering that crops up around these obscure and hard to pull off attacks. If you had said there's a 5 digit code a webpage can send to my CPU that would allow the page to do whatever it wanted with my machine then yeah I would say something drastic needs to be done, but this attack vector is never really going to be a problem for 99.9999% of people using zen 1/2/3 CPUs.
    Reply
  • DingusDog
    johnrock2 said:
    Might need to disable SMT to prevent an attack that requires an attacker to first run code on your PC in order to take advantage of the attack vector...

    Why? As far as I can tell this is another one of those "you have to be physically present at the PC" attacks or "the user has to be dumb enough to run untrusted software" schemes. Disabling SMT over something like this is like removing the turbo on your car's engine because it's possible that somebody could break into you car and rig it to behave in a way not expected. You don't cripple your equipment to spite the enemy, you fix your security.

    It's incredibly narrow sighted to strip out one of CPU technology's greatest efficiency and computational improvements to close a single hard to use attack vector. Instead You put out an advisory for those using such CPUs to process sensitive information so they can make a decision for themselves. Everyone else will get a microcode patch or an os update to fix the issue at a latter date.

    I don't get all the fear mongering that crops up around these obscure and hard to pull off attacks. If you had said there's a 5 digit code a webpage can send to my CPU that would allow the page to do whatever it wanted with my machine then yeah I would say something drastic needs to be done, but this attack vector is never really going to be a problem for 99.9999% of people using zen 1/2/3 CPUs.
    Hear! Hear!
    Reply
  • TJ Hooker
    johnrock2 said:
    Might need to disable SMT to prevent an attack that requires an attacker to first run code on your PC in order to take advantage of the attack vector...

    Why? As far as I can tell this is another one of those "you have to be physically present at the PC" attacks or "the user has to be dumb enough to run untrusted software" schemes. Disabling SMT over something like this is like removing the turbo on your car's engine because it's possible that somebody could break into you car and rig it to behave in a way not expected. You don't cripple your equipment to spite the enemy, you fix your security.

    It's incredibly narrow sighted to strip out one of CPU technology's greatest efficiency and computational improvements to close a single hard to use attack vector. Instead You put out an advisory for those using such CPUs to process sensitive information so they can make a decision for themselves. Everyone else will get a microcode patch or an os update to fix the issue at a latter date.

    I don't get all the fear mongering that crops up around these obscure and hard to pull off attacks. If you had said there's a 5 digit code a webpage can send to my CPU that would allow the page to do whatever it wanted with my machine then yeah I would say something drastic needs to be done, but this attack vector is never really going to be a problem for 99.9999% of people using zen 1/2/3 CPUs.
    I don't think anyone is suggesting Joe Blow disable SMT on his personal Ryzen computer. The relevant audience for this issue (along with most other side channel attacks, e.g. spectre/meltdown) is more or less cloud users (and hosts), where you're sharing hardware with untrusted parties by design.
    Reply
  • hotaru251
    johnrock2 said:
    Why? As far as I can tell this is another one of those "you have to be physically present at the PC" attacks or "the user has to be dumb enough to run untrusted software" schemes.
    its more for business/public place systems.

    as they have many ppl use them and does open risk.


    home users rarely ever have to worry about these.
    Reply
  • TheThief
    A different mitigation to just disabling SMT might be to just make sure SMT threads are all allocated to the same VPS of a cloud host? That way only code from the same client can be on the threads of the same core.

    Most VPSs are two or more threads anyway these days, so it may already be done that way.
    Reply
  • Viking2121
    I'll keep my SMT enabled thank ya vary much
    Reply
  • digitalgriffin
    AMD recommends software developers employ existing best practices including constant-time algorithms and avoiding secret-dependent control flows where appropriate to help mitigate this potential vulnerability," AMD's mitigation reads.

    Constant time algorithm are a rarity, when the data is random and there is conditional branching based upon that data.

    For example, even though a typical heap sort runs in O(n*log ( n ) + n), it requires moving of data in memory in arrays. Sometimes you will need to move it as you execute the heapify and then downsift. Sometimes you won't. Thus any memory move on a large array is unpredictable on run time when the data is unpredictable. Then there's the more common tournament sorts. (I prefer heap sorts for specific applications where large blocks of linear memory are available as it makes cache reads and write hits more likely)
    Reply
  • digitalgriffin
    On a side note: Questions:

    Will this delay Zen 4?
    Could this be a possible solution: Break apart the Execution keys into various small step executions that would be indistinguishable from regular code? Some secure communication channels do this to prevent packet tracing from source to target. They break apart long single packets into smaller randomly sized packets sent along different paths. This way the single source packet doesn't look like the final multiple packets on the receivers end. Obviously this would have to be done on future hardware as to not invoke a performance penalty.

    OR

    Could you isolate the core that is running RSA from other threads with a forced flush after on the tables. Dedicating a core to an RSA task on modern 6+ core processors shouldn't be an issue. Most are NOT running all their cores full tilt for this kind of work (I would imagine)
    Reply
  • digitalgriffin
    hotaru251 said:
    its more for business/public place systems.

    as they have many ppl use them and does open risk.


    home users rarely ever have to worry about these.

    Quite correct. Any developer can attack a cloud server this way. If that cloud server host more than one service, you have problems.

    I remember talking to a CEO in an elevator when Azure was released and I asked a very pointed question, "Running services on a cloud it great, until you realize the cloud is vulnerable to a common attack using the very same open services you use." He was silent and just gave me a look.

    Running your own services might be more costly, but at least you know who's accessing them, and what's running on them.

    But bean counters....
    Reply
  • svan71
    Well Intel just came out with a vulnerability so .
    Reply