This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

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