From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52478) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bkHt5-00021C-ST for qemu-devel@nongnu.org; Wed, 14 Sep 2016 17:38:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bkHt2-0002ZP-Ce for qemu-devel@nongnu.org; Wed, 14 Sep 2016 17:38:35 -0400 Received: from mx1.redhat.com ([209.132.183.28]:56954) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bkHt2-0002ZH-3F for qemu-devel@nongnu.org; Wed, 14 Sep 2016 17:38:32 -0400 Date: Thu, 15 Sep 2016 00:38:29 +0300 From: "Michael S. Tsirkin" Message-ID: <20160915001018-mutt-send-email-mst@kernel.org> References: <20160914163827-mutt-send-email-mst@kernel.org> <7a50db8e-2a3e-d7e2-6742-fcb88f8368ab@redhat.com> <20160914150213.krwad4qk3ktz5qnh@redhat.com> <6a123514-3748-eba6-e562-20183b934425@redhat.com> <20160914200533-mutt-send-email-mst@kernel.org> <5debb3c6-269b-dc76-fc81-1dd6124d2ae7@redhat.com> <20160914221147-mutt-send-email-mst@kernel.org> <2a08aa96-8b4b-19a4-e902-54d25f54d268@redhat.com> <20160914232410-mutt-send-email-mst@kernel.org> <0ffd7f15-50c5-618d-e8bd-2c711035314b@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0ffd7f15-50c5-618d-e8bd-2c711035314b@redhat.com> 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: 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 10:44:58PM +0200, Paolo Bonzini wrote: > > > On 14/09/2016 22:36, Michael S. Tsirkin wrote: > > Specifically with debug, if you have debug then clearly you > > can dump guest memory. This is what this feature is about. > > If we want a hypervisor that can not dump guest memory, let's > > add a flag like that. Does everyone have to disable debugging > > by default? I don't see why. Does everyone using encryption > > have to do this? I don't see why either. > > If you can explain what's the point in doing encryption that can be > defeated with a single ioctl, perhaps I'll agree with you. Discussed offline, I hope I clarified things. Hypervisor (host kernel) can decrypt but it is already possible for it to cause guest info leaks. But no one else on the host can. > It's okay > that we leave out features. But every feature left out is an > anti-feature baked in. Force-enable debug? You've provided a loophole > for everyone. It's already baked in by default. Let's switch it to off by default for everyone if we are worried about using monitor to leak guest secrets? Btw with a TCP socket monitor, this seems like a legitimate worry. We can do it when the new security policy object is created. > Force-disable debug? Well, of course you've blocked > debug for everyone. > > I agree that they are distinct features on the command line, but I think > you're underestimating the importance of choosing a sane default, that's it. We can safely leave that for management, but I won't object to switching the default too, let's just do it for everyone, consistently. > >> -object sev-policy-unencrypted,debug=false,id=mypolicy \ > >> -machine ...,sev-policy=mypolicy > > > > I wouldn't say sev on the command line. SEV seems to be > > a group of AMD technologies implemening memory encryption, > > measurement etc. > > > > Let's have flags for individual components: > > > > -machine ...,debug=false,memory-encryption=on,... > > I think it makes sense to have a separate -object for the policy. Let's > just make it security-policy instead of sev-policy. Brijesh, is that okay? > > Paolo OK. And some parts like blocking debug are easy enough to implement for everyone. -- MST