qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC PATCH v1 10/22] sev: add SEV debug decrypt command


From: Daniel P. Berrange
Subject: Re: [Qemu-devel] [RFC PATCH v1 10/22] sev: add SEV debug decrypt command
Date: Wed, 14 Sep 2016 14:23:14 +0100
User-agent: Mutt/1.7.0 (2016-08-17)

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 :|



reply via email to

[Prev in Thread] Current Thread [Next in Thread]