Re: [Xen-devel] xc_evtchn_status fails with EFAULT on HVM, the same on PV works

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 13/01/17 18:59, Marek Marczykowski-Górecki wrote:
> On Fri, Jan 13, 2017 at 06:37:06PM +0000, Andrew Cooper wrote:
>> On 13/01/17 18:32, Marek Marczykowski-Górecki wrote:
>>> On Fri, Jan 13, 2017 at 06:15:35PM +0000, Andrew Cooper wrote:
>>>> Can you get the result of this piece of debugging in the failure case?
>>> I've got this:
>>> ** d4v0 CFG(24, 00007f794bd07004, 1) = 24
>> Silly question (and I really hope the answer isn't yes, but I have a
>> sinking feeling it is).
>>
>> Is the guest in question using SMAP? If so, does disabling SMAP fix the
>> problem?
> How can I check that? If looking at 0x200000 CR4 bit in `xl debug-keys
> v` output enough, then yes - it's enabled. And booting hypervisor with
> smap=0 "fixed" the problem.

:(, although now I think about it, there might be a quick option.

> So, what would be the correct solution? I'd prefer not to disable SMAP
> "just" for this reason...

For the quick option, the privcmd driver in Linux needs a stac()/clac()
pair around the actual hypercall invocation, to whitelist userspace
memory accesses as being ok.

Something like this (completely untested)

andrewcoop@andrewcoop:/local/linux.git/arch/x86$ git diff
diff --git a/arch/x86/include/asm/xen/hypercall.h
b/arch/x86/include/asm/xen/hypercall.h
index a12a047..e1b2af9e 100644
--- a/arch/x86/include/asm/xen/hypercall.h
+++ b/arch/x86/include/asm/xen/hypercall.h
@@ -214,10 +214,12 @@ privcmd_call(unsigned call,
        __HYPERCALL_DECLS;
        __HYPERCALL_5ARG(a1, a2, a3, a4, a5);
 
+       stac();
        asm volatile("call *%[call]"
                     : __HYPERCALL_5PARAM
                     : [call] "a" (&hypercall_page[call])
                     : __HYPERCALL_CLOBBER5);
+       clac();
 
        return (long)__res;
 }

For the longer option, introducing a non-virtual ABI for Xen.  This is
going to become a necessary prerequisite to support AMD's Secure Virtual
Encryption technology (where the hypervisor deliberately cannot follow
the pagetables), and would remove the overhead of Xen having to walk the
guest pagetables.

Another optimisation would be to alter some of the ops to pass their
parameters in registers rather than in memory.  There are quite a few
ops which pass pointers to a single int, which could be completed more
efficiently by Xen (for both PV and HVM guests) by avoiding the memory
access entirely.

~Andrew

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