From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: [PATCH] [HVM] Patches to make HVM capable of running OS/2. Date: Fri, 16 Mar 2007 19:07:58 +0000 Message-ID: References: <515922b50703161122v4fd3df38v3b92dfd426f5db29@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1276301872==" Return-path: In-Reply-To: <515922b50703161122v4fd3df38v3b92dfd426f5db29@mail.gmail.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Mime-version: 1.0 Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Trolle Selander , Keir Fraser Cc: Mats.Petersson@amd.com, xen-devel@lists.xensource.com, thomas.woller@amd.com List-Id: xen-devel@lists.xenproject.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1276301872== Content-type: multipart/alternative; boundary="B_3256916879_53907547" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3256916879_53907547 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Possibly, but I think that allocating, registering and tracking the pages i= f they were owned by dom0 would be harder. I don;t have a clear idea how we=B9d do it without changes to the dom0 kernel. Meanwhile, domUs have plenty of other shared-memory protocols with dom0 kernel and root processes. It just needs some care to make sure the interface is sufficiently narrow and arguments are well checked. Burning 100% CPU is not considered a successful attack (although it would of course be annoying!). You can detect it and fix it up without rebooting the system= , for example. Anyway, I didn=B9t take your e801 patch, but checked in my own fix as changeset 14415. It should hit the main public tree in a few hours, or you can see it in the staging tree sooner (http://xenbits.xensource.com/staging/xen-unstable.hg). All your other patches are in except the smsw one. I=B9m looking at that now. -- Keir On 16/3/07 18:22, "Trolle Selander" wrote: > Keeping them out of the guest's way is good enough for my current practic= al > concerns, and this was the path my patch took, after all. > For the record, though, I do think that the most correct thing would be t= o > have the iopage & buffered_iopages owned by dom0, since they don't "belon= g" to > the domU anymore than any other data structure used by the qemu-dm proces= s. > In fact, one could argue that domU access to these pages could be a > theoretical way for a compromised domU to attack a process running as roo= t in > dom0. From what I've seen, the worst that can practically be done at the > moment is making qemu-dm lock up while eating 100% cpu (by setting the > buffered_iopage->read_pointer > buffered_iopage->read_pointer) but more e= vil > minds than mine might be able to figure out a way to exploit this in a wo= rse > way.=20 --B_3256916879_53907547 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [Xen-devel] [PATCH] [HVM] Patches to make HVM capable of running= OS/2. Possi= bly, but I think that allocating, registering and tracking the pages if they= were owned by dom0 would be harder. I don;t have a clear idea how we’= d do it without changes to the dom0 kernel.

Meanwhile, domUs have plenty of other shared-memory protocols with dom0 ker= nel and root processes. It just needs some care to make sure the interface i= s sufficiently narrow and arguments are well checked. Burning 100% CPU is no= t considered a successful attack (although it would of course be annoying!).= You can detect it and fix it up without rebooting the system, for example.<= BR>
Anyway, I didn’t take your e801 patch, but checked in my own fix as c= hangeset 14415. It should hit the main public tree in a few hours, or you ca= n see it in the staging tree sooner (http://xenbits.xensource.com/staging/xen-unstable.= hg).

All your other patches are in except the smsw one. I’m looking at tha= t now.

 -- Keir

On 16/3/07 18:22, "Trolle Selander" <trolle.selander@gmail.com= > wrote:

Keeping them out of the guest's way is good enough for = my current practical concerns, and this was the path my patch took, after al= l.
For the record, though, I do think that the most correct thing would be to = have the iopage & buffered_iopages owned by dom0, since they don't "= ;belong" to the domU anymore than any other data structure used by the = qemu-dm process.
In fact, one could argue that domU access to these pages could be a theoret= ical way for a compromised domU to attack a process running as root in dom0.= From what I've seen, the worst that can practically be done at the moment i= s making qemu-dm lock up while eating 100% cpu (by setting the buffered_iopa= ge->read_pointer > buffered_iopage->read_pointer) but more evil min= ds than mine might be able to figure out a way to exploit this in a worse wa= y.

--B_3256916879_53907547-- --===============1276301872== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============1276301872==--