From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60046) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bkAx7-0003Dq-O7 for qemu-devel@nongnu.org; Wed, 14 Sep 2016 10:14:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bkAx2-0007o2-0E for qemu-devel@nongnu.org; Wed, 14 Sep 2016 10:14:16 -0400 Received: from mx1.redhat.com ([209.132.183.28]:57502) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bkAx1-0007nt-QT for qemu-devel@nongnu.org; Wed, 14 Sep 2016 10:14:11 -0400 References: <147377800565.11859.4411044563640180545.stgit@brijesh-build-machine> <147377810767.11859.4668503556528840901.stgit@brijesh-build-machine> <20160914052034-mutt-send-email-mst@kernel.org> <4f4370ee-bc29-3427-7e6e-a18d50c27ffc@redhat.com> <20160914155913-mutt-send-email-mst@kernel.org> <0fd3cbb9-9e46-9373-e989-acb45b56e8a9@redhat.com> <20160914132314.GR28399@redhat.com> <20160914163045-mutt-send-email-mst@kernel.org> <20160914133749.GT28399@redhat.com> <20160914164859-mutt-send-email-mst@kernel.org> <20160914140845.GD24695@thinpad.lan.raisama.net> From: Paolo Bonzini Message-ID: Date: Wed, 14 Sep 2016 16:14:04 +0200 MIME-Version: 1.0 In-Reply-To: <20160914140845.GD24695@thinpad.lan.raisama.net> 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: Eduardo Habkost , "Michael S. Tsirkin" Cc: "Daniel P. Berrange" , Brijesh Singh , 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 16:08, Eduardo Habkost wrote: >> > If attacker can trigger things, IOW execute code in hypervisor, >> > then encrypting memory is not useful anyway. > I believe the whole point of SEV attestation and key management > is to make "if attacker can executed code in hypervisor, > encrypting memory is not useful" _not_ true, isn't it? > > Or are there known vulnerabilities that would allow a compromised > hypervisor to decrypt memory even after successful > encryption+attestation? There are countless side channels that you can use but you have to start somewhere, and anyway a side channel attack is way way more complex than just "trigger a debug dump and read it". Paolo