Even if the CPU does not -- as is the case for SEV-SNP -- you can replay prior values. Imagine a variable that contains "the current user is an admin". You can wait for an admin to log in, back up the encrypted copy of that variable, and then log in yourself and overwrite the variable to your backed up encrypted copy.
The granularity of the encryption is only 16 bytes, and so you can pretty directly target changing things at a pretty low level. And, as the encryption is deterministic, you can also characterize "this location in memory only ever seems to have three values, and they correspond to these three ciphertexts".
> If the CPU used the same key for all secure VM's to encrypt RAM, then this makes a little more sense. Just start a malicious VM, have it instruct the hardware bug to re-direct it's reads to an another VM's secured RAM, and it's game over. But that isn't exactly it, because of the requirement to have write access.
It isn't quite this, as the address matters for the encryption tweak. To do the attack this way (which is only one way of doing it: the Battering RAM device reactivates all the prior attacks, not just this one devastating one), you have to shut down the VM and boot up the malicious one, and get it aligned to the same place.
But, the key bit you are missing is... just do it in reverse? You boot up the malicious VM, have it write anything you want to write, and then you read it back using the redirect (the goal isn't to alias encrypted pages, it is to alias encrypted pages to unencrypted memory). Now you know what you can write to that location in another VM to get that value.
The granularity of the encryption is only 16 bytes, and so you can pretty directly target changing things at a pretty low level. And, as the encryption is deterministic, you can also characterize "this location in memory only ever seems to have three values, and they correspond to these three ciphertexts".
> If the CPU used the same key for all secure VM's to encrypt RAM, then this makes a little more sense. Just start a malicious VM, have it instruct the hardware bug to re-direct it's reads to an another VM's secured RAM, and it's game over. But that isn't exactly it, because of the requirement to have write access.
It isn't quite this, as the address matters for the encryption tweak. To do the attack this way (which is only one way of doing it: the Battering RAM device reactivates all the prior attacks, not just this one devastating one), you have to shut down the VM and boot up the malicious one, and get it aligned to the same place.
But, the key bit you are missing is... just do it in reverse? You boot up the malicious VM, have it write anything you want to write, and then you read it back using the redirect (the goal isn't to alias encrypted pages, it is to alias encrypted pages to unencrypted memory). Now you know what you can write to that location in another VM to get that value.