AMD processors - power side channel on cache line data changes: MULTI-TENANT ISOLATION: An authenticated attacker

Impact

MULTI-TENANT ISOLATION: An authenticated attacker who can read CPU power consumption can infer data as it moves through a shared cache line, because the energy cost of a write depends on how many bits flip. Collide+Power generalised this into a technique that works against any victim sharing the cache hierarchy, without needing the victim to have any specific code pattern. Leakage rates are low - this is not a fast exfiltration channel - but it is a channel that exists between tenants on the same socket regardless of what your isolation configuration says.

Who can reach it

Local, authenticated, needs access to power/energy telemetry (RAPL-style interfaces) and cache co-residency with the victim. Reachable from a container if you expose power telemetry into it, which some GPU and CPU monitoring stacks do.

What to do

Mitigated primarily by restricting who can read fine-grained power telemetry: on Linux, the RAPL/energy interfaces should be root-only (this was tightened upstream), and you should not be passing power monitoring into tenant containers. Check what your DCGM-equivalent AMD telemetry stack exposes and to whom - operators often mount host telemetry paths into monitoring sidecars that tenants can reach. Kernel/driver-level fix plus a config review; no firmware flash and no reboot if you are only tightening permissions. 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