I think you might be confusing Battering RAM with the recent attacks Heracles and Relocate+Vote? Regardless, these pages are not being "relocated": they are being remapped to a different physical location not to use a different key, but to be able to read/write the ciphertext itself by way of a separate unencrypted address.
TME-MK thereby doesn't do much against this attack. I mean, I guess it slightly improves one of the attacks in the paper (as Intel's CPU was especially bad with the encryption, using the same key across multiple VMs; AMD did not have this issue), but you can use Battering RAM to just get a ciphertext sidechannel (similar to WireTap).
Like, think about it this way: the real attack here is that, for any given block of memory (and these blocks are tiny: 16 bytes large), the encryption key + tweak doesn't change with every write... this is the same for TME and TME-MK. This means that you can find 16 bytes that are valuable, characterize the possible values, and dump a key.
It would be nice to understand what is going on here, but I'm missing some key point.
I gather the data written to DRAM is encrypted when written, and decrypted when read. This hardware screws with the address lines on command, so this encrypted data is read or written from some other RAM location. That allows an external party to overwrite / mutate the cipher block read back.
It's been said several times here if the secured app can detect it's RAM has been changed (eg, by Merkle trees), then the attack doesn't work. So it's not the ability to read the secure apps encrypted data in RAM that matters, you also need the ability to change it.
But surely the attacker must have to change the data into something that makes sense to the secured app. In other words, it must write a cipher block that when decrypted is changed to some known plain text. Surely it can only do that with a key.
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 a another VM's secured RAM, and it's game over. But that isn't exactly it, because of the requirement to have write access.
I am surprised the CPU uses the same AES key (or a simple derivation of the one base key) for all hosted VM's. I always imagined each hosted VM would get it's own key.
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.
TME-MK thereby doesn't do much against this attack. I mean, I guess it slightly improves one of the attacks in the paper (as Intel's CPU was especially bad with the encryption, using the same key across multiple VMs; AMD did not have this issue), but you can use Battering RAM to just get a ciphertext sidechannel (similar to WireTap).
Like, think about it this way: the real attack here is that, for any given block of memory (and these blocks are tiny: 16 bytes large), the encryption key + tweak doesn't change with every write... this is the same for TME and TME-MK. This means that you can find 16 bytes that are valuable, characterize the possible values, and dump a key.