[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] out of bounds handling for get_mfn_from_gpfn()




On 26 Apr 2006, at 14:21, Jan Beulich wrote:

The tables you mention above are not involved in get_mfn_from_gpfn() --
they translate the other way.

???
xen/include/asm-x86/mm.h says:

Ah, yes, p2m table actually steals the read-only m2p memory area for translated guests. So it's that area you're interested in (not the RW_MPT, which really is always the m2p table).

The input gpfn either needs testing
against, or masking with, (PADDR_MASK >> PAGE_SHIFT). We should always
ensure that the m2p and p2m tables are big enough to be indexed by that
value.

From the above header excerpt I'm getting the impression that mfn-s are assumed to be at most 31 bits in size (bit 31 is used as an invalid indicator there). Also, in the observed case the mfn is a 39-bit value, which is clearly inside the range covered by (PADDR_MASK >> PAGE_SHIFT) (40 bits), however, (RO_MPT_VIRT_END - RO_MPT_VIRT_START) covers only 38 bits (where, for the full 40-bit MFN range, 43 bits would be needed, which would cover the entire current hypervisor
address space reservation).

Okay, maybe we need to be more restrictive: 20 bits for 32b (4GB), 22 bits for 32b-pae (16GB), and some suitable large value for 64b (31 would be fine, it's good for up to 8TB).

It'd be nice to set PADDR_BITS appropriately and use a value derived from that, but the currently-chosen (larger) values are important for pte checking. If we exclude bits from the pte's pfn check by making PADDR_BITS smaller then we'll have to deal with the high-order pte bits some other way (perhaps by folding them into the value returned by e.g., l1e_get_flags()).

 -- Keir


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.