AMD SEV, SEV-ES and SEV-SNP

SEV encrypts the memory of each guest with a key of its own, which the AMD Secure Processor manages; the hypervisor is not trusted. SEV-ES also encrypts a guest’s register state, and SEV-SNP adds the reverse map table (RMP), which records which guest owns each page, so that a hypervisor can no longer remap guest memory. AMD’s bulletins date SEV-SNP from the third generation of EPYC (Milan); the first two generations have SEV and SEV-ES.

Most of these CVEs are in the SEV firmware or in the platform initialization (PI) firmware that AMD ships to board makers; a bulletin gives, for each EPYC generation, the PI version that fixes a CVE and often a hot-loadable SEV firmware or microcode update, with the TCB value that a guest’s attestation report shows once it is in place. Attacks that need physical access to the board are outside SEV-SNP’s threat model, and AMD’s briefs on them, listed below without CVEs, offer no fix.

Bulletins that also cover the Secure Processor, SMU or SMM list here only their SEV CVEs.

CVEs

CVEs without a page of their own

The sources give these CVEs too few facts of their own (affected processors, a mitigation, a check) for a page; this is what they say.

Advisories