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

[Marek Marczykowski-Górecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx>]

On Fri, Jan 13, 2017 at 07:54:01PM +0000, Andrew Cooper wrote:
> 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.

Hmm, if that's the case, isn't the above patch also effectively breaking
SMAP? I see the purpose of SMAP is to prevent _accidental_ access to
arbitrary, guest controlled memory. For example because of some memory
corruption bug in the hypervisor. If such a bug could be triggered using
a hypercall, then the above patch also makes SMAP useless.  Patching
copy_from_guest/copy_to_guest on the other hand would only allow such
guest controlled memory access when hypervisor is really supposed to
access guest memory.

> This bug doesn't
> manifest for PV guests, and you are probably the first person to do any
> serious hypercall work from HVM userspace.

That's interesting. I'm just trying to use slightly modified
libxenchan...

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

Attachment: signature.asc
Description: PGP signature

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