From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= Subject: Re: xc_evtchn_status fails with EFAULT on HVM, the same on PV works Date: Fri, 13 Jan 2017 21:32:23 +0100 Message-ID: <20170113203223.GO1341@mail-itl> References: <20170113173130.GI5268@mail-itl> <20170113180348.GJ5268@mail-itl> <3f9e01ca-3450-6af9-eb0c-8c867c3a6f96@citrix.com> <20170113183239.GK5268@mail-itl> <20170113185922.GL1341@mail-itl> <0c47b88f-4130-a9b8-cf93-89ae03b25dab@citrix.com> <20170113194052.GB18728@mail-itl> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5827075347712292818==" Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: Andrew Cooper Cc: xen-devel List-Id: xen-devel@lists.xenproject.org --===============5827075347712292818== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="umrsQkkrw7viUWFs" Content-Disposition: inline --umrsQkkrw7viUWFs Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 13, 2017 at 07:54:01PM +0000, Andrew Cooper wrote: > On 13/01/17 19:40, Marek Marczykowski-G=C3=B3recki wrote: > > On Fri, Jan 13, 2017 at 07:27:20PM +0000, Andrew Cooper wrote: > >> On 13/01/17 18:59, Marek Marczykowski-G=C3=B3recki wrote: > >>> On Fri, Jan 13, 2017 at 06:37:06PM +0000, Andrew Cooper wrote: > >>>> On 13/01/17 18:32, Marek Marczykowski-G=C3=B3recki 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 c= ase? > >>>>> I've got this: > >>>>> ** d4v0 CFG(24, 00007f794bd07004, 1) =3D 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=3D0 "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); > >> =20 > >> + stac(); > >> asm volatile("call *%[call]" > >> : __HYPERCALL_5PARAM > >> : [call] "a" (&hypercall_page[call]) > >> : __HYPERCALL_CLOBBER5); > >> + clac(); > >> =20 > >> 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). >=20 > Not really. (I mean - there is, but it involves deliberately breaking > SMAP support in Xen.) >=20 > 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... --=20 Best Regards, Marek Marczykowski-G=C3=B3recki 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? --umrsQkkrw7viUWFs Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJYeTlXAAoJENuP0xzK19csC1YH/3pWSEurI5orqrtR/X7tSwc2 0N4vpKgwMXYD52NwsvJ4yegatpMMOdbdLa+/bNkkNSOSMizu/9Jbw0oNXU295CqH G9GdpFE30UmwxRcNsa8NJpOQs6R6iaRIuai7tXz9qUEkwtdPuGgEzVt2l0PNsCSm U1czdSN6RNvG3FnZIVYrx+qZuZAFvFmpUyVhhvf6hxVyfY+M5mjEIWMJ1rsXPHsq JKcn4yeDx1+Pcc9XeOC5Dgx7dptVnnG7q1OGFctlYBvKfqWEWEdhkO5N7OwSEx32 ugyYV8FgnvgA12AV29cLhOptSy7sYx0uqMszR5KWtKEjlaDVn6DBjLUaOn6TN1k= =vs57 -----END PGP SIGNATURE----- --umrsQkkrw7viUWFs-- --===============5827075347712292818== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v cmcveGVuLWRldmVsCg== --===============5827075347712292818==--