Skip to contentSkip to conversation

WTF: patch "[PATCH] x86/xen: allow userspace access during hypercalls" was seriously submitted to be applied to the 4.12-stable tree?

PATCH [email protected] 2 participants 3 messages Jul 24, 2017 – Jul 25, 2017

Subsystems (3)
lore
Share & tools
lore

[email protected]

author maintainer
#0 lore raw

The patch below was submitted to be applied to the 4.12-stable tree.

I fail to see how this patch meets the stable kernel rules as found at Documentation/process/stable_kernel_rules.rst.

I could be totally wrong, and if so, please respond to <[email protected]> and let me know why this patch should be applied. Otherwise, it is now dropped from my patch queues, never to be seen again.

thanks,

greg k-h

------------------ original commit in Linus's tree ------------------

Quoted 1 line

From c54590cac51db8ab5fd30156bdaba34af915e629 Mon Sep 17 00:00:00 2001

From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?=
<[email protected]>
Date: Mon, 26 Jun 2017 14:49:46 +0200
Subject: [PATCH] x86/xen: allow userspace access during hypercalls
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

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.

arch/x86/include/asm/xen/hypercall.h +8 -1
index 7a4db5fefd15..11071fcd630e 100644
@@ -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>
@@ -216,10 +217,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;
 }
@@ -478,7 +481,11 @@ static inline int
 HYPERVISOR_dm_op(
 	domid_t dom, unsigned int nr_bufs, struct xen_dm_op_buf *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
#1 lore raw
Quoted 9 lines · On Mon, Jul 24, 2017 at 04:45:02PM -0700, [email protected] wrote:

The patch below was submitted to be applied to the 4.12-stable tree.

I fail to see how this patch meets the stable kernel rules as found at Documentation/process/stable_kernel_rules.rst.

I could be totally wrong, and if so, please respond to <[email protected]> and let me know why this patch should be applied. Otherwise, it is now dropped from my patch queues, never to be seen again.

This is a fix for -EFAULT on (any?) usage of /dev/xen/privcmd from inside of Xen HVM guest with SMAP enabled. Details in this thread:
http://markmail.org/message/b6wxaipxbjyhiueg

Quoted 67 lines

thanks,

greg k-h

------------------ original commit in Linus's tree ------------------

From c54590cac51db8ab5fd30156bdaba34af915e629 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?=
<[email protected]>
Date: Mon, 26 Jun 2017 14:49:46 +0200
Subject: [PATCH] x86/xen: allow userspace access during hypercalls
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

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.

arch/x86/include/asm/xen/hypercall.h +8 -1
index 7a4db5fefd15..11071fcd630e 100644
@@ -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>
@@ -216,10 +217,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;
 }
@@ -478,7 +481,11 @@ static inline int
 HYPERVISOR_dm_op(
 	domid_t dom, unsigned int nr_bufs, struct xen_dm_op_buf *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
Signature · 5 lines
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?
author maintainer
#2 lore raw
Quoted 6 lines · Marek Marczykowski-G�recki
Quoted 5 lines · On Mon, Jul 24, 2017 at 04:45:02PM -0700, [email protected] wrote:

The patch below was submitted to be applied to the 4.12-stable tree.

I fail to see how this patch meets the stable kernel rules as found at Documentation/process/stable_kernel_rules.rst.

Quoted 8 lines
Quoted 4 lines

I could be totally wrong, and if so, please respond to <[email protected]> and let me know why this patch should be applied. Otherwise, it is now dropped from my patch queues, never to be seen again.

This is a fix for -EFAULT on (any?) usage of /dev/xen/privcmd from inside of Xen HVM guest with SMAP enabled. Details in this thread:
http://markmail.org/message/b6wxaipxbjyhiueg

Why wasn't that information in the changelog itself? As it is it lookes like a "here's a new feature" type of patch...

I'll go queue this up now, thanks.

greg k-h