From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54427) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bkY7f-0002YB-DK for qemu-devel@nongnu.org; Thu, 15 Sep 2016 10:58:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bkY7Z-0005kh-Fy for qemu-devel@nongnu.org; Thu, 15 Sep 2016 10:58:42 -0400 Received: from mx1.redhat.com ([209.132.183.28]:45312) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bkY7Z-0005kU-6a for qemu-devel@nongnu.org; Thu, 15 Sep 2016 10:58:37 -0400 Date: Thu, 15 Sep 2016 11:58:30 -0300 From: Eduardo Habkost Message-ID: <20160915145830.GE6002@thinpad.lan.raisama.net> References: <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> <20160914150632.GX28399@redhat.com> <20160914181816-mutt-send-email-mst@kernel.org> <20160914173541.GF24695@thinpad.lan.raisama.net> <20160914211803-mutt-send-email-mst@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160914211803-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: "Daniel P. Berrange" , Paolo Bonzini , Brijesh Singh , crosthwaite.peter@gmail.com, p.fedin@samsung.com, qemu-devel@nongnu.org, armbru@redhat.com, lcapitulino@redhat.com, rth@twiddle.net On Thu, Sep 15, 2016 at 01:05:12AM +0300, Michael S. Tsirkin wrote: [...] > > > Attestation seems mostly unrelated. The whitepaper says > > > With this attestation, a guest owner can ensure that the hypervisor did > > > not interfere with the initialization of SEV before transmitting > > > confidential information to the guest. > > > which seems to imply an active attacker that is able to interfere > > > with the hypervisor during guest initialization but not afterwards. > > > > I believe this assumes a compromised hypervisor both before and > > after guest launch, but this assumes the hypervisor: > > 1) Won't be able to change guest memory before attestation > > without being detected. > > 2) Won't be able to attack the guest after memory is encrypted. > > Why would you need to measure things then? If you assume this, at what > point *can* attacker change memory? I am assuming an attacker that can change memory at any moment. If memory is changed before encryption, measurement/attestation would detect it. And I assume that memory changes after encryption won't cause much damage except crashing the guest. > > > > So I have no idea why that's useful at the moment - I suspect > > > it's part of the future vision when there are protections > > > against all active attackers in place, but for now it seems to extend the > > > firmware/software interface unnecessarily. > > > > "Protection against all active attackers" is a very broad > > requirement. Effective protection against a given subset of > > attacks would be reasonable enough to me. > > Well selecting a random point in time and saying "I protect against > attacks at this point only" would be a very weak protection, akin to > just adding an assert statement at a random place in code - even though > yes, if you hit that assert you are protected. > > This is not to say this is what this patchset does, merely > that it should include a bit more information about the > motivation for the measurement part than > "this is what we can easily implement". Agreed that we need more information about the attacks they have in mind. -- Eduardo