AMD SEV / SEV-ES / SEV-SNP - ciphertext observability: MULTI-TENANT ISOLATION: SEV encrypts guest memory

Impact

MULTI-TENANT ISOLATION: SEV encrypts guest memory deterministically per physical address, so the same plaintext at the same address always produces the same ciphertext. A malicious hypervisor that can read the encrypted pages watches ciphertext blocks change over time and infers the plaintext values underneath - the CipherLeaks researchers recovered full RSA and ECDSA private keys out of the SEV-protected VMSA this way. This is the deepest structural problem in the SEV family: it is a consequence of the encryption mode, not a coding bug, so it cannot simply be patched away.

Who can reach it

Requires a malicious or compromised hypervisor with the ability to read guest ciphertext - the exact adversary SEV exists to defeat. No guest bug needed.

What to do

Partially mitigated: AMD added ciphertext-hiding for the VMSA in SEV-SNP firmware, delivered through AGESA/SEV firmware as an OEM SBIOS package with the usual **one to six month lag** and a drained-node power cycle, plus a TCB bump that requires refreshing VCEK certificates. On newer parts, SEV-SNP Ciphertext Hiding can be enabled to block host reads of guest ciphertext outright - check whether your platform and firmware support it and turn it on. The residual risk on older EPYC generations is **not fully fixable**: guest software must avoid keeping secrets in memory patterns an observer can correlate, which is a burden you cannot impose on a tenant's workload. Be honest with confidential-computing customers about which EPYC generation their VM lands on.

References