[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] [PATCH] [HVM] Patches to make HVM capable of running OS/2.
- To: "Keir Fraser" <keir@xxxxxxxxxxxxx>
- From: "Trolle Selander" <trolle.selander@xxxxxxxxx>
- Date: Fri, 16 Mar 2007 19:22:41 +0100
- Cc: Mats.Petersson@xxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxx, thomas.woller@xxxxxxx
- Delivery-date: Fri, 16 Mar 2007 11:21:41 -0700
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=dYR7MIQ6iyj/PV+eopNfFv9gpMsvt7yWaCA01NiqF94NAMVs2JqqJ/dBMVxZS1Ctt7mlErG3A/vygXG8C44Gqnx/GqdbvDh2wG0zC4iTgH9mnNOs0ljp/9VNwFbdHmYlj3VG0sRshB/wL61l/qgQUldm4169n03EmyJ+6HEk6WA=
- List-id: Xen developer discussion <xen-devel.lists.xensource.com>
On 3/16/07, Keir Fraser <keir@xxxxxxxxxxxxx
> wrote:
On 16/3/07 12:45, "Trolle Selander" <trolle.selander@xxxxxxxxx> wrote:
I thought they were marked as reserved in the e820 map right now, but now that I checked, you're right that they're not mentioned, which means they're actually nearly as "unprotected" from a modern OS as from a pre-e820-aware one like OS/2. Nasty.
In any case, I still don't see why the ioreq and buffered io pages should be inside the guest's memory space at all. What's the issue with keeping them completely outside the guest's visible RAM and only shared between HV & Dom0?
If the pages belong to the domU then they have to be part of its pseudophysical address space, otherwise dom0 cannot map them (since HVM pages are always mapped by pfn, not by mfn).
We could make the pages belong to dom0, or to Xen, I suppose, but that's not the road we've gone down and there's not really any reason to change now. We should just keep the pages out of the guest's way so he doesn't accidentally use them as RAM or map on top of them!
-- Keir
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
|
