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

Re: [Xen-devel] [PATCH v4 0/3] x86: modify_ldt improvement, test, and config option



On 07/29/2015 03:03 PM, Andrew Cooper wrote:
On 29/07/15 15:43, Boris Ostrovsky wrote:
FYI, I have got a repro now and am investigating.
Good and bad news.  This bug has nothing to do with LDTs themselves.

I have worked out what is going on, but this:

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 5abeaac..7e1a82e 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -493,6 +493,7 @@ static void set_aliased_prot(void *v, pgprot_t prot)
pte = pfn_pte(pfn, prot); + (void)*(volatile int*)v;
         if (HYPERVISOR_update_va_mapping((unsigned long)v, pte, 0)) {
                 pr_err("set_aliased_prot va update failed w/ lazy mode
%u\n", paravirt_get_lazy_mode());
                 BUG();

Is perhaps not the fix we are looking for, and every use of
HYPERVISOR_update_va_mapping() is susceptible to the same problem.

I think in most cases we know that page is mapped so hopefully this is the only site that we need to be careful about.


The update_va_mapping hypercall is designed to emulate writing the pte
for v, with auditing applied.  As part of this, it does a pagewalk on v
to locate and map the l1.  During this walk, Xen it finds the l2 not
present, and fails the hypercall.  i.e. v is not reachable from the
current cr3.

Reading the virtual address immediately before issuing the hypercall
causes Linux's memory faulting logic to fault in the l2.  This also
explains why vm_unmap_aliases() appears to fix the issue; it is likely
to fault in enough of the paging structure for v to be reachable.

We've just touched this page (in write_ldt()) in this test so why would it not be mapped?



One solution might be to use MMU_NORMAL_PT_UPDATE hypercall instead,
which take the physical address of pte to update.  This won't fail in
Xen if part of the paging structure is missing, and can be batched.

Yes, it does work. Thanks Andrew.


-boris

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

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