From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42686) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bkH3O-0004U6-D1 for qemu-devel@nongnu.org; Wed, 14 Sep 2016 16:45:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bkH3J-0006G7-CP for qemu-devel@nongnu.org; Wed, 14 Sep 2016 16:45:09 -0400 Received: from mx1.redhat.com ([209.132.183.28]:50526) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bkH3J-0006G2-0z for qemu-devel@nongnu.org; Wed, 14 Sep 2016 16:45:05 -0400 References: <20160914052034-mutt-send-email-mst@kernel.org> <4bf6d983-3ecf-9350-3791-74022c06aa51@amd.com> <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> From: Paolo Bonzini Message-ID: <0ffd7f15-50c5-618d-e8bd-2c711035314b@redhat.com> Date: Wed, 14 Sep 2016 22:44:58 +0200 MIME-Version: 1.0 In-Reply-To: <20160914232410-mutt-send-email-mst@kernel.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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: 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 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. 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. 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. >> -object sev-policy-unencrypted,debug=3Dfalse,id=3Dmypolicy \ >> -machine ...,sev-policy=3Dmypolicy >=20 > I wouldn't say sev on the command line. SEV seems to be > a group of AMD technologies implemening memory encryption, > measurement etc. >=20 > Let's have flags for individual components: >=20 > -machine ...,debug=3Dfalse,memory-encryption=3Don,... 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 oka= y? Paolo