AMD Zen 1 / Zen 2 / Zen 3 - execution unit scheduler queue contention (SMT): MULTI-TENANT ISOLATION: AMD's split

Impact

MULTI-TENANT ISOLATION: AMD's split scheduler design gives each execution unit its own queue, and contention on those queues is observable from the sibling SMT thread. An attacker running on one hardware thread measures scheduler pressure and reconstructs what the co-resident thread is computing - the SQUIP researchers recovered a full RSA-4096 private key from a victim on the sibling thread. This is a genuine cross-tenant confidentiality break with no memory access involved at all: nothing in your container, VM or cgroup boundary sees it happening, because no boundary is crossed in software.

Who can reach it

Local, unprivileged, requires SMT enabled and the attacker scheduled on the sibling thread of the victim's physical core. On a bin-packed cluster that co-residency happens by default - your scheduler arranges it for you. Affects Zen 1, Zen 2 and Zen 3.

What to do

AMD's guidance is that software should use constant-time / secret-independent control flow rather than a microcode fix, so **treat this as effectively unpatchable in hardware**. The operator-side controls are the real answer: disable SMT on nodes that mix tenants, or enforce whole-core (not thread) allocation so a physical core is never shared across trust boundaries. Kubernetes operators can get this with the CPU manager's full-pcpus-only policy. Disabling SMT needs a reboot; core-pinning policy needs a kubelet restart and a drain. The zero-cost mitigation available today is scheduling policy rather than patching: these attacks need the attacker and victim co-resident on sibling SMT threads, so either disable SMT (costing roughly 10-25% throughput on most inference and training workloads) or enforce core isolation so no two tenants ever share a physical core. On a GPU fleet the CPU is rarely the bottleneck, which makes disabling SMT a cheaper trade than it looks on paper.

References