From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33189) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bkB2R-0007Zg-I5 for qemu-devel@nongnu.org; Wed, 14 Sep 2016 10:19:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bkB2N-0001AJ-NO for qemu-devel@nongnu.org; Wed, 14 Sep 2016 10:19:46 -0400 Received: from mx1.redhat.com ([209.132.183.28]:47334) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bkB2N-0001A6-Hd for qemu-devel@nongnu.org; Wed, 14 Sep 2016 10:19:43 -0400 References: <147377800565.11859.4411044563640180545.stgit@brijesh-build-machine> <147377810767.11859.4668503556528840901.stgit@brijesh-build-machine> <20160914052034-mutt-send-email-mst@kernel.org> <4bf6d983-3ecf-9350-3791-74022c06aa51@amd.com> <20160914163827-mutt-send-email-mst@kernel.org> From: Paolo Bonzini Message-ID: <7a50db8e-2a3e-d7e2-6742-fcb88f8368ab@redhat.com> Date: Wed, 14 Sep 2016 16:19:38 +0200 MIME-Version: 1.0 In-Reply-To: <20160914163827-mutt-send-email-mst@kernel.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit 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" , Brijesh Singh Cc: 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 15:48, Michael S. Tsirkin wrote: >> One of the bit in policy field is "debugging", if this bit is set then >> hypervisor can use SEV commands to decrypt a guest memory > > That is my point. Arbitrary code execution in hypervisor means game over > anyway, at least with the hardware we have today. Game is over if you assume the attacker has infinite power. In practice the attacker may be limited by other security features (SELinux, seccomp, external firewalls, whatever), by the money and time they can spend on the attack. So anything that makes things harder for the attacker is a security improvement. > My suggestion is to merge the support for encrypting memory first, > then make extras like disabling debugging on top. Sorry but I concur with others that this makes no sense at all. If anything, it's *enabling* debugging that can be done on top. That said... > I can't say I understand how does guest measuring help prevent > leaks in any way. Looks like a separate feature - why not split it > out? ... the patch series seems to be pretty small and self contained. I don't see any point in splitting it further. Paolo