From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48433) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bkAEI-0000gT-Ph for qemu-devel@nongnu.org; Wed, 14 Sep 2016 09:28:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bkAEE-0001VL-28 for qemu-devel@nongnu.org; Wed, 14 Sep 2016 09:27:58 -0400 Received: from mx1.redhat.com ([209.132.183.28]:59872) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bkAED-0001V9-Sq for qemu-devel@nongnu.org; Wed, 14 Sep 2016 09:27:53 -0400 Date: Wed, 14 Sep 2016 16:27:51 +0300 From: "Michael S. Tsirkin" Message-ID: <20160914161507-mutt-send-email-mst@kernel.org> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0fd3cbb9-9e46-9373-e989-acb45b56e8a9@redhat.com> Subject: Re: [Qemu-devel] [PATCH v2] virtio_pci: Limit DMA mask to 44 bits for legacy virtio devices 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, p.fedin@samsung.com, qemu-devel@nongnu.org, armbru@redhat.com, lcapitulino@redhat.com, rth@twiddle.net On Wed, Sep 14, 2016 at 03:07:58PM +0200, Paolo Bonzini wrote: > > > On 14/09/2016 15:05, Michael S. Tsirkin wrote: > > I assumed that with debug on, memory is still encrypted but the > > hypervisor can break encryption, and as the cover letter states, the > > hypervisor is assumed benign. If true I don't see a need to > > give users more rope. > > The hypervisor is assumed benign but vulnerable. Vulnerable to information leaks, yes. > So, if somebody breaks the hypervisor, you would like to make it as hard > as possible We don't just do this at random. Need some proof it's actually making things harder. > for the attacker to do evil stuff to the guests. Break as in make it do things? This is a possible model, but this is not what the cover letter states. As far as I can tell, encrypting memory does not protect against an attacker that can execute code in the hypervisor, if only for the reason that a lot of guest info is not in memory as CPU always accesses memory through registers. > If the > attacker can just ask the secure processor "decrypt some memory for me", > then the encryption is effectively broken. > > Paolo Not at all, if all you have is hypervisor read-anywhere access, then that is not broken. This seems to be the threat model that the patchset targets, again based on the cover letter. -- MST