From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33423) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bk05N-000899-HW for qemu-devel@nongnu.org; Tue, 13 Sep 2016 22:38:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bk05K-0004KA-DK for qemu-devel@nongnu.org; Tue, 13 Sep 2016 22:38:05 -0400 Received: from mx1.redhat.com ([209.132.183.28]:52300) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bk05K-0004K0-83 for qemu-devel@nongnu.org; Tue, 13 Sep 2016 22:38:02 -0400 Date: Wed, 14 Sep 2016 05:38:00 +0300 From: "Michael S. Tsirkin" Message-ID: <20160914053334-mutt-send-email-mst@kernel.org> References: <147377800565.11859.4411044563640180545.stgit@brijesh-build-machine> <147377822450.11859.5845767550630184079.stgit@brijesh-build-machine> <45717d25-176b-dd80-98cc-d91ee0e354fc@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45717d25-176b-dd80-98cc-d91ee0e354fc@redhat.com> Subject: Re: [Qemu-devel] [RFC PATCH v1 22/22] loader: reload bios image on ROM reset in SEV-enabled guest List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Brijesh Singh , ehabkost@redhat.com, crosthwaite.peter@gmail.com, armbru@redhat.com, p.fedin@samsung.com, qemu-devel@nongnu.org, lcapitulino@redhat.com, rth@twiddle.net On Wed, Sep 14, 2016 at 12:59:32AM +0200, Paolo Bonzini wrote: > > > On 13/09/2016 16:50, Brijesh Singh wrote: > > In SEV-enabled mode we need to reload the BIOS image on loader reset, this > > will ensure that BIOS image gets encrypted and included as part of launch > > meausrement on guest reset. > > Just to check if I understand correctly, the secure processor cannot > split the encryption and measuring, which is why you need to redo the > copy on every reset. > > Does the guest have to check the measured data (e.g. with a hash) too, > to check that it hasn't been tampered with outside the secure > processor's control? I don't know what does measurement mean in this context as this patchset was supposed to be about protecting memory so you don't get to steal guest secrets just because you get to steal hypervisor secrets. Guest checking anything at all seems highly unlikely to help in this context, as they probably already happened by the time guest is checking things. > Of course this would result in garbage written to > the modified page, but that might be a valid attack vector. > > Paolo