The majority of AMD’s CPU lineup – essentially any processor using Zen 1, Zen 2, or Zen 3 cores with simultaneous multithreading (SMT) enabled – is vulnerable to a newly disclosed side channel attack.
The Scheduler Queue Usage via Interface Probing attack, or SQUIP for short, was detailed in a paper published by researchers at Lamarr Security Research, Graz University of Technology, and Georgia Institute of Technology.
SQUIP exploits AMD’s use of multiple schedulers to manage out-of-order execution of instructions on the CPU. The approach enables more efficient use of CPU resources and by extension higher performance, which is further accelerated through the use of SMT.
While side channel attacks targeting these kinds of order pipelines are nothing new – Spectre and Meltdown were the big ones a few years back – researchers contend this is the first to attack the CPU scheduler.
The attack works by measuring the contention between the multiple schedulers used in modern AMD processors to exfiltrate sensitive data. The researchers note that AMD isn’t the only chipmaker using multiple schedulers. It should be noted that Intel’s current crop of CPUs rely on a single scheduler and thus aren’t vulnerable to the attack vector.
“We first reverse-engineer the behavior of the scheduler queues on these CPUs and show that they can be primed and probed,” researchers wrote.
Using this methodology, researchers were able to exfiltrate data from a VM collocated on the processor at a rate of 0.89 Mbit/sec with an error rate of less than 1 percent. The attack was even more effective for co-located processes, where they were able to extract data at a rate of 2.7 Mbit/sec while maintaining an error rate of less than 1 percent. This was demonstrated by extracting an intact RSA-4096 key from a co-located VM.
“As shown, using the SQUIP side channel, an unprivileged attacker can extract sensitive information from a co-located victim within less than 45 minutes,” the paper reads.
What’s more, researchers found that the Epyc server CPU’s secure encrypted virtualization (SEV) functionality, which provides additional security for shared hosting environments, by encrypting the contents of the memory, doesn’t prevent leakage across VMs that allow SMT when faced with a SQUIP attack.
However, as the researchers point out, there are numerous avenues for mitigating this threat, though many will require re-architecting.
The attack relies on four conditions to be met for it to be successful, the researchers explain. For one the CPUs execution units must be connected to multiple schedulers, that those execution units have different capabilities, that the co-located processors compete for free slots in the scheduler queues, and that the flow control for RSA implementation is secret dependent.
“Without any of these four prerequisites, the demonstrated attack no longer works,” the paper reads.
Because of this, other processors with multiple schedulers like Apple’s M1 and M2 weren’t found to be vulnerable to the SQUIP attack because they lacked SMT. However, if that ever changes and Apple does implement SMT, researchers postulate that the M-series chips could be vulnerable to SQUIP.
The researchers highlight several potential hardware and software mitigations for the attack. From a hardware perspective, they write that future AMD designs could avoid the vulnerability by using a single scheduler architecture, making the schedulers symmetrical, or by isolating hardware threads more strictly in the scheduler queues.
However, existing Ryzen, Threadripper, and Epyc customers are stuck with software mitigations, which largely rely on software and OS vendors to update their applications to prevent exploitation, and the only surefire fix appears to be to disable SMT.
For its part, AMD was made aware of the vulnerability late last year and has acknowledged the side channel attack and assigned it a medium severity under CVE-2021-46778.
The chipmaker’s recommendation is to “employ existing best practices, including constant-time algorithms and avoiding secret-dependent control flows where appropriate to help mitigate this potential vulnerability.”
However, AMD stops short of recommending customers disable SMT, which is hardly surprisingly given that would have severe performance implications.
Be the first to comment