WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] out of bounds handling for get_mfn_from_gpfn()
From: "Jan Beulich" <jbeulich@xxxxxxxxxx>
Date: Wed, 26 Apr 2006 14:01:16 +0200
Delivery-date: Wed, 26 Apr 2006 05:00:55 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Since get_mfn_from_gpfn() exclusively relies on recovering from a potential 
page fault resulting from an ill gpfn passed
in, I wonder if it is considered the responsibility of the caller to ensure the 
gpfn is at least within bounds for
phys_to_machine_mapping[]. We are having a bug report where the function 
happens to access (due to way out of bound a
gpfn, the origin of which I have yet to determine) the GDT/LDT space and hence, 
instead of recovering, hits the BUG_ON()
in handle_gdt_ldt_mapping_fault().

Assuming it doing the bounds checking is not reasonable to be the 
responsibility of the caller, I further wonder in
which of the two possible places the bug should be fixed:
- convert the BUG_ON() in handle_gdt_ldt_mapping_fault() to a conditional, 
calling search_exception_table() when VCPU
and area don't match(and skipping all of the processing and returning just zero 
in the opposite case if recovery code
was found), and only BUG()ing when no recovery code can be found
- add a bounds check to get_mfn_from_gpfn() (in which case I'd be uncertain 
what the correct boundary is, since on 64
bits (RO_MPT_VIRT_END - RO_MPT_VIRT_START) != (RDWR_MPT_VIRT_END - 
RDWR_MPT_VIRT_START), and only one of the two ranges
can be the correct one)

Thanks, Jan

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