On Wed, Sep 14, 2016 at 03:07:58PM +0200, Paolo Bonzini wrote: > > > On 14/09/2016 15:05, Michael S. Tsirkin wrote: > > I assumed that with debug on, memory is still encrypted but the > > hypervisor can break encryption, and as the cover letter states, the > > hypervisor is assumed benign. If true I don't see a need to > > give users more rope. > > The hypervisor is assumed benign but vulnerable. > > So, if somebody breaks the hypervisor, you would like to make it as hard > as possible for the attacker to do evil stuff to the guests. If the > attacker can just ask the secure processor "decrypt some memory for me", > then the encryption is effectively broken.
So there's going to be a tradeoff here between use of SEV and use of certain other features. eg, it seems that if you're using SEV, then any concept of creating & analysing guest core dumps from the host is out. It seems that SEV on its own is insufficient - there is at least some interaction with storage. eg merely running a guest with SEV is not going to guarantee security if the guest OS is able to swap out to a non-encrypted disk. You could run LUKS inside the guest but that has a number of downsides. How to provide the decryption key for LUKS at startup without guest admin interaction. Then there is the issue that if you take snapshots of the guest disk in the host, this is weakening the security of LUKS, since you're keeping around copies of the same logical guest sector with different contents which allows for improve crytoanalysis. These are reasons for using LUKS on the host instead of in the guest, but then the decryption kjeys for LUKS are in the QEMU process in memory which is (IIUC) not going to be protected by SEV ? Unles there's a way for QEMU to do allocations which are SEV protected for its own purposes ? Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
