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

["Jan Beulich" <jbeulich@xxxxxxxxxx>]

>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:

/*
 * The phys_to_machine_mapping is the reversed mapping of MPT for full
 * virtualization.  It is only used by shadow_mode_translate()==true
 * guests, so we steal the address space that would have normally
 * been used by the read-only MPT map.
 */
#define phys_to_machine_mapping ((unsigned long *)RO_MPT_VIRT_START)
#define INVALID_MFN             (~0UL)
#define VALID_MFN(_mfn)         (!((_mfn) & (1U<<31)))

#define set_mfn_from_gpfn(pfn, mfn) (phys_to_machine_mapping[(pfn)] = (mfn))
static inline unsigned long get_mfn_from_gpfn(unsigned long pfn)
{
    unsigned long mfn;

    if ( __copy_from_user(&mfn, &phys_to_machine_mapping[pfn], sizeof(mfn)) )
        mfn = INVALID_MFN;

    return mfn;
}

>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).

Jan

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