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

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

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