I'll add that disabling swap is not good for host stability (and still cannot prevent leaks caused by crashes)
But it reduces leaks, at least?
My experience is on the contrary. As soon as the host swaps, the system becomes super slow. Unusable for moments. Since I disabled swap (enough RAM), my experience has been improved.
Memory dumps caused by BSOD or kernel crashes can still leave unintenteded traces on the host even with in-guest encryption and following the (unrealistic) rules.
Good point. Please add this to the wiki.
KVM guests are Linux processes and subject to Linux memory allocation rules. Its not possible that a VM process accesses the data of memory pages that belonged to another process.
True. But besides the point. I mean something else...
"When a VM has been powered down, the RAM that previously contained the VM's encryption key might not have been wiped yet? Smilar to cold boot attacks, but in this case it might even be a "warm" attack, because under this threat model, the machine and RAM is still powered." -> The threat model here is, that the attack examines the computer while it's still powered on. In such as situation, the encryption key could still be in RAM, even if the VM was just powered down.
Linux zeroes out (i.e. fills with zeros) all pages of memory not when they are released, but when they are given to another process. Thus, no process may obtain data excerpts from another process. However, the pages will retain their old contents until they are reused. I am not aware of any patch which does the zeroing upon page release
That strengthens my point. As long as the RAM that was previously used by the VM was not assigned to another process, the adversary can try a root escalation + load kernel module, or local kernel exploit and cold boot attack to extract the VMs encryption key.