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: [email protected]
Signed-off-by: Marek Marczykowski-Górecki <[email protected]>
---
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
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: [email protected]
> Signed-off-by: Marek Marczykowski-Górecki <[email protected]>
> ---
> 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;
> }
>
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?
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: [email protected]
Signed-off-by: Marek Marczykowski-Górecki <[email protected]>
---
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
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: [email protected]
> Signed-off-by: Marek Marczykowski-Górecki <[email protected]>
Reviewed-by: Juergen Gross <[email protected]>
Thanks,
Juergen
> -----Original Message-----
> From: Xen-devel [mailto:[email protected]] On Behalf Of
> Marek Marczykowski-Górecki
> Sent: 26 June 2017 13:45
> To: Juergen Groß <[email protected]>
> Cc: Andrew Cooper <[email protected]>; [email protected]; linux-
> [email protected]; [email protected]; xen-
> [email protected]; Boris Ostrovsky <[email protected]>
> 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?
On Mon, Jun 26, 2017 at 01:09:58PM +0000, Paul Durrant wrote:
> > -----Original Message-----
> > From: Xen-devel [mailto:[email protected]] On Behalf Of
> > Marek Marczykowski-Górecki
> > Sent: 26 June 2017 13:45
> > To: Juergen Groß <[email protected]>
> > Cc: Andrew Cooper <[email protected]>; [email protected]; linux-
> > [email protected]; [email protected]; xen-
> > [email protected]; Boris Ostrovsky <[email protected]>
> > 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?
> -----Original Message-----
> From: 'Marek Marczykowski-Górecki'
> [mailto:[email protected]]
> Sent: 26 June 2017 14:22
> To: Paul Durrant <[email protected]>
> Cc: Juergen Groß <[email protected]>; Andrew Cooper
> <[email protected]>; [email protected]; linux-
> [email protected]; [email protected]; xen-
> [email protected]; Boris Ostrovsky <[email protected]>
> 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:[email protected]] On Behalf Of
> > > Marek Marczykowski-Górecki
> > > Sent: 26 June 2017 13:45
> > > To: Juergen Groß <[email protected]>
> > > Cc: Andrew Cooper <[email protected]>; [email protected];
> linux-
> > > [email protected]; [email protected]; xen-
> > > [email protected]; Boris Ostrovsky
> <[email protected]>
> > > 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?
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: [email protected]
> Signed-off-by: Marek Marczykowski-Górecki <[email protected]>
Queued to xen/tip.git for-linus-4.13
Thanks,
Juergen