containerd (default mounts, /sys/devices/virtual/powercap RAPL): Containers get read access to Intel RAPL power

Impact

Containers get read access to Intel RAPL power telemetry by default, which is the PLATYPUS attack surface. Fine-grained energy readings leak information about what the host CPU is doing, and were demonstrated against AES-NI keys (including inside SGX enclaves) and against KASLR. The kernel restricted this to root in 5.10, but that mitigation misses the container case: without user namespaces, root in a container is root for this purpose, and sysfs being mounted read-only does not help because reading is the entire attack. On a bare-metal multi-tenant GPU host — the standard neocloud shape, where a tenant gets a real container on real hardware rather than a VM — one tenant can measure the power behaviour of workloads belonging to another tenant or of the host itself. RAPL is only present on bare metal with the powercap module compiled in, so cloud VMs are out of scope and bare-metal GPU fleets are precisely in scope.

Who can reach it

Local, from inside any container on an affected bare-metal host with RAPL/powercap available and an unpatched or unmitigated CPU. Root inside the container, without user namespaces, is enough; only read access to sysfs is required.

What to do

Upgrade containerd past 1.6.25 / 1.7.10 so /sys/devices/virtual/powercap is masked in the default mount configuration, and drain the node for the runtime restart. Independently: apply the CPU microcode updates that coarsened RAPL sampling resolution, enable user namespaces for tenant containers, and confirm the mask is actually present in running containers rather than assuming the default applies to workloads started before the upgrade.

References