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: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).

> 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.

Yes, but it will not solve all the cases.

-- 
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