Re: [Xen-devel] [PATCH] [HVM] Patches to make HVM capable of running OS/2.

[Keir Fraser <keir@xxxxxxxxxxxxx>]

Possibly, 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 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’t 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’m looking at that now.

 -- Keir

On 16/3/07 18:22, "Trolle Selander" <trolle.selander@xxxxxxxxx> 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 all.
> 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 theoretical 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 is making qemu-dm lock up while eating 100% cpu (by setting the buffered_iopage->read_pointer > buffered_iopage->read_pointer) but more evil minds than mine might be able to figure out a way to exploit this in a worse way. 




_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel