From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NlrmK-00063E-Oz for qemu-devel@nongnu.org; Sun, 28 Feb 2010 17:38:24 -0500 Received: from [199.232.76.173] (port=53170 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NlrmK-000631-Dl for qemu-devel@nongnu.org; Sun, 28 Feb 2010 17:38:24 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1NlrmJ-0005FL-3B for qemu-devel@nongnu.org; Sun, 28 Feb 2010 17:38:24 -0500 Received: from mail-gw0-f45.google.com ([74.125.83.45]:60776) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NlrmI-0005FE-R4 for qemu-devel@nongnu.org; Sun, 28 Feb 2010 17:38:22 -0500 Received: by gwj16 with SMTP id 16so79633gwj.4 for ; Sun, 28 Feb 2010 14:38:22 -0800 (PST) Message-ID: <4B8AF05C.7060705@codemonkey.ws> Date: Sun, 28 Feb 2010 16:38:20 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <886ef6ffeb6748f6dc4fe5431f71cb12bb74edc9.1267122331.git.mst@redhat.com> <4B86D3CF.4020601@codemonkey.ws> <20100226145155.GC23359@redhat.com> <4B87E755.9000707@codemonkey.ws> <20100227194418.GB26389@redhat.com> <4B8A94FA.5020000@codemonkey.ws> <20100228171920.GE28921@redhat.com> <4B8AD8D4.7070002@codemonkey.ws> <20100228210128.GA731@redhat.com> In-Reply-To: <20100228210128.GA731@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCHv2 10/12] tap: add vhost/vhostfd options List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: amit.shah@redhat.com, Paul Brook , quintela@redhat.com, qemu-devel@nongnu.org, kraxel@redhat.com On 02/28/2010 03:01 PM, Michael S. Tsirkin wrote: > On Sun, Feb 28, 2010 at 02:57:56PM -0600, Anthony Liguori wrote: > >> On 02/28/2010 11:19 AM, Michael S. Tsirkin wrote: >> >>>> Both have security implications so I think it's important that they >>>> be addressed. Otherwise, I'm pretty happy with how things are. >>>> >>>> >>> Care suggesting some solutions? >>> >>> >> The obvious thing to do would be to use the memory notifier in vhost to >> keep track of whenever something remaps the ring's memory region and if >> that happens, issue an ioctl to vhost to change the location of the >> ring. >> > It would be easy to do, but what I wondered about, is what happens in the > guest meanwhile. Which ring address has the correct descriptors: the old > one? The new one? Both? This question leads me to the belief that well-behaved > guest will never encounter this. > This is not a question of well-behaved guests. It's a question about what our behaviour is in the face of a malicious guest. While I agree with you that that behaviour can be undefined, writing to an invalid ram location I believe could lead to guest privilege escalation. I think the two solutions we could implement would be to always use the latest mapping (which is what all code does today) or to actively prevent ram from being remapped (which is my proposal below). Regards, Anthony Liguori