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 19:40, Marek Marczykowski-Górecki wrote:
> On Fri, Jan 13, 2017 at 07:27:20PM +0000, Andrew Cooper wrote:
>> 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;
>>  }
> Is there any option to do that from hypervisor side? For example somehow
> modify copy_from_guest/copy_to_guest? I'm not always controlling the VM
> kernel (for example sometimes I need to cope with the one from Debian
> stable).

Not really.  (I mean - there is, but it involves deliberately breaking
SMAP support in Xen.)

This is a guest kernel bug.  The guest kernel has used SMAP to say
"please disallow all userspace accesses", and Xen is respecting this
when trying to follow the pointer in the hypercall.  This bug doesn't
manifest for PV guests, and you are probably the first person to do any
serious hypercall work from HVM userspace.

~Andrew

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