From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55858) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bmlpH-0000Iu-1U for qemu-devel@nongnu.org; Wed, 21 Sep 2016 14:00:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bmlpC-0005oR-52 for qemu-devel@nongnu.org; Wed, 21 Sep 2016 14:00:55 -0400 Received: from mx1.redhat.com ([209.132.183.28]:56354) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bmlpB-0005nv-VS for qemu-devel@nongnu.org; Wed, 21 Sep 2016 14:00:50 -0400 Date: Wed, 21 Sep 2016 21:00:47 +0300 From: "Michael S. Tsirkin" Message-ID: <20160921180047.eiifndz6vuooxc47@redhat.com> References: <147377800565.11859.4411044563640180545.stgit@brijesh-build-machine> <147377820679.11859.11888810000954712438.stgit@brijesh-build-machine> <20160914052834-mutt-send-email-mst@kernel.org> <2ccb51d4-3f68-5c6e-5c73-c4a5779939cc@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2ccb51d4-3f68-5c6e-5c73-c4a5779939cc@redhat.com> Subject: Re: [Qemu-devel] [RFC PATCH v1 20/22] fw_cfg: sev: disable dma in real mode Message-ID: <20160921205731-mutt-send-email-mst@kernel.org> 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, p.fedin@samsung.com, qemu-devel@nongnu.org, armbru@redhat.com, lcapitulino@redhat.com, rth@twiddle.net On Wed, Sep 14, 2016 at 10:58:08AM +0200, Paolo Bonzini wrote: > > > On 14/09/2016 04:33, Michael S. Tsirkin wrote: > > Frankly I don't understand why do you need to mess with boot at all. > > Quoting the cover letter: > > > > SEV is designed to protect guest VMs from a benign but vulnerable > > (i.e. not fully malicious) hypervisor. In particular, it reduces the > > attack > > surface of guest VMs and can prevent certain types of VM-escape bugs > > (e.g. hypervisor read-anywhere) from being used to steal guest data. > > > > it seems highly unlikely that any secret data is used during boot. > > So just let guest boot normally, and encrypt afterwards. > > > > Even assuming there are some guests that have secret data during boot, > > I would first upstream the main part of the feature for normal guests, > > then weight the extra security if any against the features and > > performance lost (like slower boot times). > > If you can't trust boot, any encryption done afterwards is totally > pointless. > > Paolo You trust hypervisor anyway, it's all mitigation, being about making attacks harder, isn't it? So if the attack has to happen in the window when guest boots within BIOS, that might be good enough. Or just don't boot in the cloud, move guest there after boot. -- MST