Why was encrypting virtual machine memory alone considered insufficient in VM-based TEEs, so that mechanisms protecting memory integrity were added, as in AMD SEV-SNP?

Answer: C. Even without being able to read the contents, the hypervisor can change page mappings or write back old ciphertext and thereby disrupt the virtual machine

With early memory encryption, the hypervisor could not read the ciphertext but could remap the virtual machine's pages to other locations, write back old ciphertext it had saved earlier (replay) or corrupt the ciphertext. When ciphertext is altered, the decrypted result merely turns into an unpredictable value, so the virtual machine cannot notice the tampering, and research demonstrated attacks that used this as a foothold. In SEV-SNP the CPU checks a table (the RMP) that records, for each physical page, the virtual machine that owns it and the address it maps to, preventing the hypervisor from writing to a virtual machine's pages or swapping their mappings. According to public documents as of the mid-2020s, advanced physical attacks such as directly manipulating the memory bus during operation are outside what SEV-SNP protects against.

• A. The key exists only inside the CPU and the hypervisor cannot decrypt. Being unable to read and being unable to modify are separate problems.
• B. Encryption does not change the usable memory capacity.
• C. Correct. Not only confidentiality but also integrity, which prevents tampering and substitution, is needed.