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

To: "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] out of bounds handling for get_mfn_from_gpfn()
From: "Jan Beulich" <jbeulich@xxxxxxxxxx>
Date: Wed, 26 Apr 2006 15:21:34 +0200
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 26 Apr 2006 06:21:36 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <d9c1614cb7566c6aeb2c16eb68d203d4@xxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <444F7D2C.76E4.0078.0@xxxxxxxxxx> <d9c1614cb7566c6aeb2c16eb68d203d4@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>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 

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


Xen-devel mailing list