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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Jul 24, 2017 at 04:45:02PM -0700, gregkh@xxxxxxxxxxxxxxxxxxx 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 
> <stable@xxxxxxxxxxxxxxx> 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

> 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?=
>  <marmarek@xxxxxxxxxxxxxxxxxxxxxx>
> 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.
> 
> Cc: stable@xxxxxxxxxxxxxxx
> Signed-off-by: Marek Marczykowski-Górecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx>
> Reviewed-by: Juergen Gross <jgross@xxxxxxxx>
> Signed-off-by: Juergen Gross <jgross@xxxxxxxx>
> 
> diff --git a/arch/x86/include/asm/xen/hypercall.h b/arch/x86/include/asm/xen/hypercall.h
> index 7a4db5fefd15..11071fcd630e 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>
> @@ -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
> 

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


[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]