From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47182) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bkBlr-0008UF-Ol for qemu-devel@nongnu.org; Wed, 14 Sep 2016 11:06:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bkBlm-0001Z4-6R for qemu-devel@nongnu.org; Wed, 14 Sep 2016 11:06:42 -0400 Received: from mx1.redhat.com ([209.132.183.28]:38071) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bkBll-0001Yq-UA for qemu-devel@nongnu.org; Wed, 14 Sep 2016 11:06:38 -0400 Date: Wed, 14 Sep 2016 16:06:33 +0100 From: "Daniel P. Berrange" Message-ID: <20160914150632.GX28399@redhat.com> Reply-To: "Daniel P. Berrange" References: <20160914052034-mutt-send-email-mst@kernel.org> <4f4370ee-bc29-3427-7e6e-a18d50c27ffc@redhat.com> <20160914155913-mutt-send-email-mst@kernel.org> <0fd3cbb9-9e46-9373-e989-acb45b56e8a9@redhat.com> <20160914132314.GR28399@redhat.com> <20160914163045-mutt-send-email-mst@kernel.org> <20160914133749.GT28399@redhat.com> <20160914164859-mutt-send-email-mst@kernel.org> <20160914141507.GU28399@redhat.com> <20160914173830-mutt-send-email-mst@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20160914173830-mutt-send-email-mst@kernel.org> Subject: Re: [Qemu-devel] [RFC PATCH v1 10/22] sev: add SEV debug decrypt command List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: Paolo Bonzini , Brijesh Singh , ehabkost@redhat.com, crosthwaite.peter@gmail.com, p.fedin@samsung.com, qemu-devel@nongnu.org, armbru@redhat.com, lcapitulino@redhat.com, rth@twiddle.net On Wed, Sep 14, 2016 at 05:48:17PM +0300, Michael S. Tsirkin wrote: > On Wed, Sep 14, 2016 at 03:15:07PM +0100, Daniel P. Berrange wrote: > > On Wed, Sep 14, 2016 at 04:50:51PM +0300, Michael S. Tsirkin wrote: > > > On Wed, Sep 14, 2016 at 02:37:49PM +0100, Daniel P. Berrange wrote: > > > > On Wed, Sep 14, 2016 at 04:32:44PM +0300, Michael S. Tsirkin wrote: > > > > > On Wed, Sep 14, 2016 at 02:23:14PM +0100, Daniel P. Berrange wrote: > > > > > > 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. > > > > > > > > > > I don't see why - as long as we don't trigger dumps, there's no leak :) > > > > > > > > If the facility to trigger dumps is available, then the memory > > > > encryption feature of SEV is as useful as a chocolate teapot, > > > > as the would be attacker can simply trigger a dump > > > > > > If attacker can trigger things, IOW execute code in hypervisor, > > > then encrypting memory is not useful anyway. > > > > The presentation at KVM forum claimed it *would* protect against > > this, and that things like core dump of unencrypted memory would > > not be permitted, so there's a disconnect between that preso and > > what you're saying. > > > > Regards, > > Daniel > > You mean presentation claimed protection against leaks to a malicious > active attacker within a hypervisor? I guess the presentation covers > more than this patchset does then. And the disconnect would be with > what the patchset cover letter says, not just with what I say. Clearly > encrypting memory is not enough to protect against a malicious > hypervisor. E.g. just running info cpus is enough to leak information > from guest. It was explicit about the fact that the host admin would not have any way to get access to the full contents of guest memory, without the guest admin granting it. Only those non-encrypted pages used for I/O transfer between host & guest would be accessible. 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 :|