AMD Posts Linux Patches for Enhanced SMT Protection on SEV-SNP VMs

ESMTP lets a confidential VM's sibling threads run its own vCPUs instead of idling, with hardware rather than the host enforcing who shares a core. It's opt-in and carries a performance cost.
AMD Posts Linux Patches for Enhanced SMT Protection on SEV-SNP VMs
AMD Posts Linux Patches for Enhanced SMT Protection on SEV-SNP VMs

AMD engineers have posted the first Linux kernel patches for Enhanced SMT Protection (ESMTP), a hardware feature meant to stop SEV-SNP confidential virtual machines from sharing a CPU core with untrusted threads, Phoronix reported.

AMD published a specification for the feature in March without much notice. Given the timing of the Linux work, Phoronix expects it to arrive with the EPYC 9006 “Venice” server processors.

What it changes

ESMTP extends AMD’s existing SMT Protection, which requires a protected vCPU’s sibling thread to sit idle. Under ESMTP, the sibling can either be idle in host mode or run a vCPU from the same VM, “which allows more efficient use of hardware multi-threading resources,” the spec says. Guests can also declare which of their vCPUs may share a core.

The kernel patch series describes the goal: while one of a VM’s vCPUs is in guest mode, “every SMT sibling thread on that physical core is either idle in host mode or running a vCPU the guest itself has declared a legal sibling,” which “mitigates the side-channel risk of sharing core resources with untrusted host threads or with another guest.”

The key difference from Linux core scheduling is who enforces it. “Unlike core scheduling, where co-residency is a host kernel policy expressed with cookies, ESMTP is enforced by hardware,” the patches say, so the host isn’t trusted to run its own work on a sibling thread while an ESMTP vCPU is active.

How it works

Support shows up in CPUID Fn8000_0025_EDX bit 1, and guests turn it on with SEV_FEATURES bit 17. It can’t be combined with the original SMT Protection (bit 15); setting both makes VMRUN fail with VMEXIT_INVALID. A VCPU_ID field and a VCPU_SIBLING_MASK in the VMSA define which vCPUs may run on the same core together, and an ESMTP_TIMEOUT_CTL field in the VMCB sets how long, in P0 clocks, the processor waits to enter guest mode. When a VMRUN targets an ESMTP vCPU, the processor waits until every sibling thread is idle in host mode or running a legal sibling. VMRUN fails if a sibling runs an illegal one, if a physical interrupt arrives or if the timeout expires.

In the Linux patches, both KVM and the guest set the sibling mask so that any two vCPUs of the same guest may share a core; combined with an ASID check, a sibling is always either another vCPU of that guest or an idle host thread.

Opt-in, with a cost

ESMTP won’t be on by default. “ESMTP is opt-in because it carries a performance cost as VMRUN stalls until the sibling runs work from a trusted vCPU or is in host idle,” the patches note. It is aimed at public cloud deployments and untrusted workloads, works only with SEV-SNP, and also needs changes to QEMU and OVMF.

Subscribe for Updates

CloudSecurityUpdate Newsletter

The CloudSecurityUpdate Email Newsletter is essential for IT, security, and cloud professionals focused on protecting cloud environments. Perfect for leaders managing cloud security in a rapidly evolving landscape.

By signing up for our newsletter you agree to receive content related to ientry.com / webpronews.com and our affiliate partners. For additional information refer to our terms of service.

Notice an error?

Help us improve our content by reporting any issues you find.

Get the WebProNews newsletter delivered to your inbox

Get the free daily newsletter read by decision makers

Subscribe
Advertise with Us

Ready to get started?

Get our media kit

Advertise with Us