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

From: Boris Ostrovsky
Date: Wed Jul 29 2015 - 17:25:16 EST


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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/