[PATCH] x86/xen: allow userspace access during hypercalls

[PATCH] x86/xen: allow userspace access during hypercalls

[Marek Marczykowski-Górecki]

Userspace application can do a hypercall through /dev/xen/privcmd, and
some for some hypercalls argument is a pointers to user-provided
structure. When SMAP is supported and enabled, hypervisor can't access.
So, lets allow it.

Cc: stable@vger.kernel.org
Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
---
 arch/x86/include/asm/xen/hypercall.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/x86/include/asm/xen/hypercall.h b/arch/x86/include/asm/xen/hypercall.h
index f6d20f6..a1d2c5d 100644
--- a/arch/x86/include/asm/xen/hypercall.h
+++ b/arch/x86/include/asm/xen/hypercall.h
@@ -43,6 +43,7 @@
 
 #include <asm/page.h>
 #include <asm/pgtable.h>
+#include <asm/smap.h>
 
 #include <xen/interface/xen.h>
 #include <xen/interface/sched.h>
@@ -214,10 +215,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;
 }
-- 
2.7.4

Re: [PATCH] x86/xen: allow userspace access during hypercalls

[Juergen Groß]

On 06/23/2017 02:47 PM, Marek Marczykowski-Górecki wrote:
> Userspace application can do a hypercall through /dev/xen/privcmd, and
> some for some hypercalls argument is a pointers to user-provided
> structure. When SMAP is supported and enabled, hypervisor can't access.
> So, lets allow it.

What about HYPERVISOR_dm_op?


Juergen

> 
> Cc: stable@vger.kernel.org
> Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
> ---
>   arch/x86/include/asm/xen/hypercall.h | 3 +++
>   1 file changed, 3 insertions(+)
> 
> diff --git a/arch/x86/include/asm/xen/hypercall.h b/arch/x86/include/asm/xen/hypercall.h
> index f6d20f6..a1d2c5d 100644
> --- a/arch/x86/include/asm/xen/hypercall.h
> +++ b/arch/x86/include/asm/xen/hypercall.h
> @@ -43,6 +43,7 @@
>   
>   #include <asm/page.h>
>   #include <asm/pgtable.h>
> +#include <asm/smap.h>
>   
>   #include <xen/interface/xen.h>
>   #include <xen/interface/sched.h>
> @@ -214,10 +215,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;
>   }
> 

Re: [PATCH] x86/xen: allow userspace access during hypercalls

[Marek Marczykowski-Górecki]

[-- Attachment #1: Type: text/plain, Size: 804 bytes --]

On Mon, Jun 26, 2017 at 02:05:48PM +0200, Juergen Groß wrote:
> On 06/23/2017 02:47 PM, Marek Marczykowski-Górecki wrote:
> > Userspace application can do a hypercall through /dev/xen/privcmd, and
> > some for some hypercalls argument is a pointers to user-provided
> > structure. When SMAP is supported and enabled, hypervisor can't access.
> > So, lets allow it.
> 
> What about HYPERVISOR_dm_op?

Indeed, arguments copied to kernel space there are only addresses of
buffers. Will send v2 in a moment.
But I can't test it right now, as for my understanding this require
HVM/PVHv2 dom0 or stubdomain...

-- 
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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[PATCH v2] x86/xen: allow userspace access during hypercalls

[Marek Marczykowski-Górecki]

Userspace application can do a hypercall through /dev/xen/privcmd, and
some for some hypercalls argument is a pointers to user-provided
structure. When SMAP is supported and enabled, hypervisor can't access.
So, lets allow it.

The same applies to HYPERVISOR_dm_op, where additionally privcmd driver
carefully verify buffer addresses.

Cc: stable@vger.kernel.org
Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
---
 arch/x86/include/asm/xen/hypercall.h | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

Changes since v1:
 - add HYPERVISOR_dm_op

diff --git a/arch/x86/include/asm/xen/hypercall.h b/arch/x86/include/asm/xen/hypercall.h
index f6d20f6..32b74a8 100644
--- a/arch/x86/include/asm/xen/hypercall.h
+++ b/arch/x86/include/asm/xen/hypercall.h
@@ -43,6 +43,7 @@
 
 #include <asm/page.h>
 #include <asm/pgtable.h>
+#include <asm/smap.h>
 
 #include <xen/interface/xen.h>
 #include <xen/interface/sched.h>
@@ -214,10 +215,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;
 }
@@ -476,7 +479,11 @@ static inline int
 HYPERVISOR_dm_op(
 	domid_t dom, unsigned int nr_bufs, void *bufs)
 {
-	return _hypercall3(int, dm_op, dom, nr_bufs, bufs);
+	int ret;
+	stac();
+	ret = _hypercall3(int, dm_op, dom, nr_bufs, bufs);
+	clac();
+	return ret;
 }
 
 static inline void
-- 
2.7.4

Re: [PATCH v2] x86/xen: allow userspace access during hypercalls

[Juergen Groß]

On 06/26/2017 02:49 PM, Marek Marczykowski-Górecki wrote:
> Userspace application can do a hypercall through /dev/xen/privcmd, and
> some for some hypercalls argument is a pointers to user-provided
> structure. When SMAP is supported and enabled, hypervisor can't access.
> So, lets allow it.
> 
> The same applies to HYPERVISOR_dm_op, where additionally privcmd driver
> carefully verify buffer addresses.
> 
> Cc: stable@vger.kernel.org
> Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>

Reviewed-by: Juergen Gross <jgross@suse.com>


Thanks,

Juergen

Re: [PATCH v2] x86/xen: allow userspace access during hypercalls

[Juergen Gross]

On 26/06/17 14:49, Marek Marczykowski-Górecki wrote:
> Userspace application can do a hypercall through /dev/xen/privcmd, and
> some for some hypercalls argument is a pointers to user-provided
> structure. When SMAP is supported and enabled, hypervisor can't access.
> So, lets allow it.
> 
> The same applies to HYPERVISOR_dm_op, where additionally privcmd driver
> carefully verify buffer addresses.
> 
> Cc: stable@vger.kernel.org
> Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>

Queued to xen/tip.git for-linus-4.13


Thanks,

Juergen

RE: [Xen-devel] [PATCH] x86/xen: allow userspace access during hypercalls

[Paul Durrant]

> -----Original Message-----
> From: Xen-devel [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of
> Marek Marczykowski-Górecki
> Sent: 26 June 2017 13:45
> To: Juergen Groß <jgross@suse.com>
> Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>; x86@kernel.org; linux-
> kernel@vger.kernel.org; stable@vger.kernel.org; xen-
> devel@lists.xenproject.org; Boris Ostrovsky <boris.ostrovsky@oracle.com>
> Subject: Re: [Xen-devel] [PATCH] x86/xen: allow userspace access during
> hypercalls
> 
> On Mon, Jun 26, 2017 at 02:05:48PM +0200, Juergen Groß wrote:
> > On 06/23/2017 02:47 PM, Marek Marczykowski-Górecki wrote:
> > > Userspace application can do a hypercall through /dev/xen/privcmd, and
> > > some for some hypercalls argument is a pointers to user-provided
> > > structure. When SMAP is supported and enabled, hypervisor can't access.
> > > So, lets allow it.
> >
> > What about HYPERVISOR_dm_op?
> 
> Indeed, arguments copied to kernel space there are only addresses of
> buffers. Will send v2 in a moment.
> But I can't test it right now, as for my understanding this require
> HVM/PVHv2 dom0 or stubdomain...
> 

No, you don't need anything particularly special to use dm_op. Just up-to-date xen, privcmd, and QEMU. QEMU should end up using dm_op by default if all three are in place.

  Paul

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

Re: [Xen-devel] [PATCH] x86/xen: allow userspace access during hypercalls

['Marek Marczykowski-Górecki']

[-- Attachment #1: Type: text/plain, Size: 1702 bytes --]

On Mon, Jun 26, 2017 at 01:09:58PM +0000, Paul Durrant wrote:
> > -----Original Message-----
> > From: Xen-devel [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of
> > Marek Marczykowski-Górecki
> > Sent: 26 June 2017 13:45
> > To: Juergen Groß <jgross@suse.com>
> > Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>; x86@kernel.org; linux-
> > kernel@vger.kernel.org; stable@vger.kernel.org; xen-
> > devel@lists.xenproject.org; Boris Ostrovsky <boris.ostrovsky@oracle.com>
> > Subject: Re: [Xen-devel] [PATCH] x86/xen: allow userspace access during
> > hypercalls
> > 
> > On Mon, Jun 26, 2017 at 02:05:48PM +0200, Juergen Groß wrote:
> > > On 06/23/2017 02:47 PM, Marek Marczykowski-Górecki wrote:
> > > > Userspace application can do a hypercall through /dev/xen/privcmd, and
> > > > some for some hypercalls argument is a pointers to user-provided
> > > > structure. When SMAP is supported and enabled, hypervisor can't access.
> > > > So, lets allow it.
> > >
> > > What about HYPERVISOR_dm_op?
> > 
> > Indeed, arguments copied to kernel space there are only addresses of
> > buffers. Will send v2 in a moment.
> > But I can't test it right now, as for my understanding this require
> > HVM/PVHv2 dom0 or stubdomain...
> > 
> 
> No, you don't need anything particularly special to use dm_op. Just up-to-date xen, privcmd, and QEMU. QEMU should end up using dm_op by default if all three are in place.

But the issue this patch fixes applies only to hypercalls issued from HVM.

-- 
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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

RE: [Xen-devel] [PATCH] x86/xen: allow userspace access during hypercalls

[Paul Durrant]

> -----Original Message-----
> From: 'Marek Marczykowski-Górecki'
> [mailto:marmarek@invisiblethingslab.com]
> Sent: 26 June 2017 14:22
> To: Paul Durrant <Paul.Durrant@citrix.com>
> Cc: Juergen Groß <jgross@suse.com>; Andrew Cooper
> <Andrew.Cooper3@citrix.com>; x86@kernel.org; linux-
> kernel@vger.kernel.org; stable@vger.kernel.org; xen-
> devel@lists.xenproject.org; Boris Ostrovsky <boris.ostrovsky@oracle.com>
> Subject: Re: [Xen-devel] [PATCH] x86/xen: allow userspace access during
> hypercalls
> 
> On Mon, Jun 26, 2017 at 01:09:58PM +0000, Paul Durrant wrote:
> > > -----Original Message-----
> > > From: Xen-devel [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of
> > > Marek Marczykowski-Górecki
> > > Sent: 26 June 2017 13:45
> > > To: Juergen Groß <jgross@suse.com>
> > > Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>; x86@kernel.org;
> linux-
> > > kernel@vger.kernel.org; stable@vger.kernel.org; xen-
> > > devel@lists.xenproject.org; Boris Ostrovsky
> <boris.ostrovsky@oracle.com>
> > > Subject: Re: [Xen-devel] [PATCH] x86/xen: allow userspace access during
> > > hypercalls
> > >
> > > On Mon, Jun 26, 2017 at 02:05:48PM +0200, Juergen Groß wrote:
> > > > On 06/23/2017 02:47 PM, Marek Marczykowski-Górecki wrote:
> > > > > Userspace application can do a hypercall through /dev/xen/privcmd,
> and
> > > > > some for some hypercalls argument is a pointers to user-provided
> > > > > structure. When SMAP is supported and enabled, hypervisor can't
> access.
> > > > > So, lets allow it.
> > > >
> > > > What about HYPERVISOR_dm_op?
> > >
> > > Indeed, arguments copied to kernel space there are only addresses of
> > > buffers. Will send v2 in a moment.
> > > But I can't test it right now, as for my understanding this require
> > > HVM/PVHv2 dom0 or stubdomain...
> > >
> >
> > No, you don't need anything particularly special to use dm_op. Just up-to-
> date xen, privcmd, and QEMU. QEMU should end up using dm_op by default
> if all three are in place.
> 
> But the issue this patch fixes applies only to hypercalls issued from HVM.

Oh, I see what you mean. Well I guess you could manually run QEMU from an HVM domain, but it would be a bit of a faff to set up.

  Paul

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