From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46107) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bk62K-0000Bh-Ex for qemu-devel@nongnu.org; Wed, 14 Sep 2016 04:59:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bk62E-0005H7-Ei for qemu-devel@nongnu.org; Wed, 14 Sep 2016 04:59:19 -0400 Received: from mail-wm0-f50.google.com ([74.125.82.50]:38677) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bk62E-0005Gu-7r for qemu-devel@nongnu.org; Wed, 14 Sep 2016 04:59:14 -0400 Received: by mail-wm0-f50.google.com with SMTP id 1so17294259wmz.1 for ; Wed, 14 Sep 2016 01:59:14 -0700 (PDT) Sender: Paolo Bonzini References: <147377800565.11859.4411044563640180545.stgit@brijesh-build-machine> <147377820679.11859.11888810000954712438.stgit@brijesh-build-machine> <20160914052834-mutt-send-email-mst@kernel.org> From: Paolo Bonzini Message-ID: <2ccb51d4-3f68-5c6e-5c73-c4a5779939cc@redhat.com> Date: Wed, 14 Sep 2016 10:58:08 +0200 MIME-Version: 1.0 In-Reply-To: <20160914052834-mutt-send-email-mst@kernel.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC PATCH v1 20/22] fw_cfg: sev: disable dma in real mode List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" 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 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