[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.