SEV-SNP Concepts
Last updated
Last updated
AES encryption, as employed in AMD SEV technologies, significantly enhances memory confidentiality protection. It ensures that VM data stored in DRAM remains indecipherable to attackers without knowledge of the encryption key. The SEV memory encryption key is generated via a hardware random number generator and stored in dedicated hardware registers, inaccessible to direct software access. Moreover, the encryption mechanism ensures that the same plaintext at different memory locations will result in different ciphertexts.
While encryption provides a strong layer of defense, determined attackers may attempt integrity attacks, altering memory values without knowing the encryption key. Such attacks manipulate the data in memory, causing it to deviate from the VM's intended values. Two common types of integrity attacks are memory corruption leading to random data for the VM and replay attacks, where an attacker captures ciphertext from a previous point in time and later substitutes it back into memory.
Integrity attacks themselves do not directly compromise a VM; they only become potent when software inside the VM relies on the corrupted data, leading to potential compromises or information disclosure. The impact of such attacks depends on how the software behaves when encountering compromised data. Predicting the behavior of software in such situations becomes challenging since it typically remains unaware of its memory integrity being compromised.
SEV-SNP is specifically designed to counter software-based integrity attacks and mitigate the risks associated with compromised memory integrity. The core principle of SEV-SNP is to ensure that if a VM can read a private (encrypted) memory page, it must always retrieve the last value written to that location. If it attempts to read the memory and encounters a different value, an exception is raised to indicate that the memory cannot be read. This guarantee remains intact even if the VM undergoes memory page swapping to disk or migration to a new host. Implementing this integrity guarantee requires a combination of new CPU hardware and firmware, which will be further discussed in this white paper.
In standard use cases, VMs not only execute their tasks but also communicate with external entities through I/O operations. This communication often involves shared (unencrypted) memory. Outgoing data that the VM wishes to make available is placed in a shared memory page, and incoming data is similarly stored in a shared page. Since shared memory is not encrypted with the VM's specific key, it is vital to use appropriate software encryption protocols like HTTPS for securing I/O traffic.
AMD SEV VMs determine whether a memory page is private or shared using the Virtual Address enCrypted bit (C-bit) in the guest page tables. Private (encrypted) memory pages are exclusively for the VM's use and are marked as C=1, while shared memory pages intended for outside communication are marked as C=0. SEV-SNP integrity guarantees apply only to private guest pages, just like the SEV confidentiality guarantees.
Overall, the combination of AES encryption, SEV-SNP integrity protection, and prudent use of shared memory helps establish a robust security foundation for AMD SEV technologies, safeguarding VMs from various threats in virtualized environments.