Re: [Xen-devel] stable-rc build: 3 warnings 0 failures (stable-rc/v4.4.89-42-g255b4a0)

[gregkh]

On Wed, Oct 04, 2017 at 03:49:30PM +0200, Arnd Bergmann wrote:
> On Wed, Oct 4, 2017 at 10:41 AM, Olof's autobuilder  wrote:
> >
> > Warnings:
> >
> >   1 arm/xen/mm.c:202:2: warning: initialization from incompatible 
> > pointer type
> >   1 arm/xen/mm.c:202:2: warning: (near initialization for 
> > 'xen_swiotlb_dma_ops.mmap')
> >   1 drivers/xen/swiotlb-xen.c:697:27: warning: passing argument 6 of 
> > '__generic_dma_ops(dev)->mmap' makes pointer from integer without a cast
> 
> This is caused by backporting 2f0b82b1b830 ("swiotlb-xen: implement
> xen_swiotlb_dma_mmap callback") into stable-rc/4.4.
> 
> The ->mmap() callback signature changed in linux-4.8 as of commit
> 00085f1efa38 ("dma-mapping: use unsigned long for dma_attrs"), so
> all older kernels are affected.
> 
> Please drop the backport patch from 4.4 and 3.18, or apply the trivial fixup
> that I'll send in a bit.

Many thanks for the fixup, I've queued that up now for both trees.

greg k-h

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] Patch "x86/smpboot: Make logical package management more robust" has been added to the 4.9-stable tree

[gregkh]

This is a note to let you know that I've just added the patch titled

x86/smpboot: Make logical package management more robust

to the 4.9-stable tree which can be found at:

http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
 x86-smpboot-make-logical-package-management-more-robust.patch
and it can be found in the queue-4.9 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let  know about it.


From 9d85eb9119f4eeeb48e87adfcd71f752655700e9 Mon Sep 17 00:00:00 2001
From: Thomas Gleixner 
Date: Mon, 12 Dec 2016 11:04:53 +0100
Subject: x86/smpboot: Make logical package management more robust

From: Thomas Gleixner 

commit 9d85eb9119f4eeeb48e87adfcd71f752655700e9 upstream.

The logical package management has several issues:

 - The APIC ids provided by ACPI are not required to be the same as the
   initial APIC id which can be retrieved by CPUID. The APIC ids provided
   by ACPI are those which are written by the BIOS into the APIC. The
   initial id is set by hardware and can not be changed. The hardware
   provided ids contain the real hardware package information.

   Especially AMD sets the effective APIC id different from the hardware id
   as they need to reserve space for the IOAPIC ids starting at id 0.

   As a consequence those machines trigger the currently active firmware
   bug printouts in dmesg, These are obviously wrong.

 - Virtual machines have their own interesting of enumerating APICs and
   packages which are not reliably covered by the current implementation.

The sizing of the mapping array has been tweaked to be generously large to
handle systems which provide a wrong core count when HT is disabled so the
whole magic which checks for space in the physical hotplug case is not
needed anymore.

Simplify the whole machinery and do the mapping when the CPU starts and the
CPUID derived physical package information is available. This solves the
observed problems on AMD machines and works for the virtualization issues
as well.

Remove the extra call from XEN cpu bringup code as it is not longer
required.

Fixes: d49597fd3bc7 ("x86/cpu: Deal with broken firmware (VMWare/XEN)")
Reported-and-tested-by: Borislav Petkov 
Tested-by: Boris Ostrovsky 
Signed-off-by: Thomas Gleixner 
Cc: Juergen Gross 
Cc: Peter Zijlstra 
Cc: M. Vefa Bicakci 
Cc: xen-devel 
Cc: Charles (Chas) Williams 
Cc: Borislav Petkov 
Cc: Alok Kataria 
Link: http://lkml.kernel.org/r/alpine.DEB.2.20.1612121102260.3429@nanos
Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/kernel/apic/apic.c  |   15 
 arch/x86/kernel/cpu/common.c |   24 ++--
 arch/x86/kernel/smpboot.c|   51 ---
 arch/x86/xen/smp.c   |6 -
 4 files changed, 27 insertions(+), 69 deletions(-)

--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -2159,21 +2159,6 @@ int __generic_processor_info(int apicid,
}
 
/*
-* This can happen on physical hotplug. The sanity check at boot time
-* is done from native_smp_prepare_cpus() after num_possible_cpus() is
-* established.
-*/
-   if (topology_update_package_map(apicid, cpu) < 0) {
-   int thiscpu = max + disabled_cpus;
-
-   pr_warning("APIC: Package limit reached. Processor %d/0x%x 
ignored.\n",
-  thiscpu, apicid);
-
-   disabled_cpus++;
-   return -ENOSPC;
-   }
-
-   /*
 * Validate version
 */
if (version == 0x0) {
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -979,29 +979,21 @@ static void x86_init_cache_qos(struct cp
 }
 
 /*
- * The physical to logical package id mapping is initialized from the
- * acpi/mptables information. Make sure that CPUID actually agrees with
- * that.
+ * Validate that ACPI/mptables have the same information about the
+ * effective APIC id and update the package map.
  */
-static void sanitize_package_id(struct cpuinfo_x86 *c)
+static void validate_apic_and_package_id(struct cpuinfo_x86 *c)
 {
 #ifdef CONFIG_SMP
-   unsigned int pkg, apicid, cpu = smp_processor_id();
+   unsigned int apicid, cpu = smp_processor_id();
 
apicid = apic->cpu_present_to_apicid(cpu);
-   pkg = apicid >> boot_cpu_data.x86_coreid_bits;
 
-   if (apicid != c->initial_apicid) {
-   pr_err(FW_BUG "CPU%u: APIC id mismatch. Firmware: %x CPUID: 
%x\n",
+   if (apicid != c->apicid) {
+   pr_err(FW_BUG "CPU%u: APIC id mismatch. 

[Xen-devel] Patch "x86/mm/xen: Suppress hugetlbfs in PV guests" has been added to the 4.4-stable tree

[gregkh]

This is a note to let you know that I've just added the patch titled

x86/mm/xen: Suppress hugetlbfs in PV guests

to the 4.4-stable tree which can be found at:

http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
 x86-mm-xen-suppress-hugetlbfs-in-pv-guests.patch
and it can be found in the queue-4.4 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let  know about it.


From 103f6112f253017d7062cd74d17f4a514ed4485c Mon Sep 17 00:00:00 2001
From: Jan Beulich 
Date: Thu, 21 Apr 2016 00:27:04 -0600
Subject: x86/mm/xen: Suppress hugetlbfs in PV guests

From: Jan Beulich 

commit 103f6112f253017d7062cd74d17f4a514ed4485c upstream.

Huge pages are not normally available to PV guests. Not suppressing
hugetlbfs use results in an endless loop of page faults when user mode
code tries to access a hugetlbfs mapped area (since the hypervisor
denies such PTEs to be created, but error indications can't be
propagated out of xen_set_pte_at(), just like for various of its
siblings), and - once killed in an oops like this:

  kernel BUG at .../fs/hugetlbfs/inode.c:428!
  invalid opcode:  [#1] SMP
  ...
  RIP: e030:[]  [] 
remove_inode_hugepages+0x25b/0x320
  ...
  Call Trace:
   [] hugetlbfs_evict_inode+0x15/0x40
   [] evict+0xbd/0x1b0
   [] __dentry_kill+0x19a/0x1f0
   [] dput+0x1fe/0x220
   [] __fput+0x155/0x200
   [] task_work_run+0x60/0xa0
   [] do_exit+0x160/0x400
   [] do_group_exit+0x3b/0xa0
   [] get_signal+0x1ed/0x470
   [] do_signal+0x14/0x110
   [] prepare_exit_to_usermode+0xe9/0xf0
   [] retint_user+0x8/0x13

This is CVE-2016-3961 / XSA-174.

Reported-by: Vitaly Kuznetsov 
Signed-off-by: Jan Beulich 
Cc: Andrew Morton 
Cc: Andy Lutomirski 
Cc: Boris Ostrovsky 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: David Vrabel 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Juergen Gross 
Cc: Linus Torvalds 
Cc: Luis R. Rodriguez 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: Toshi Kani 
Cc: xen-devel 
Link: http://lkml.kernel.org/r/57188ed80278000e4...@prv-mh.provo.novell.com
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/include/asm/hugetlb.h |1 +
 1 file changed, 1 insertion(+)

--- a/arch/x86/include/asm/hugetlb.h
+++ b/arch/x86/include/asm/hugetlb.h
@@ -4,6 +4,7 @@
 #include 
 #include 
 
+#define hugepages_supported() cpu_has_pse
 
 static inline int is_hugepage_only_range(struct mm_struct *mm,
 unsigned long addr,


Patches currently in stable-queue which might be from jbeul...@suse.com are

queue-4.4/x86-mm-xen-suppress-hugetlbfs-in-pv-guests.patch

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] Patch "x86/mm/xen: Suppress hugetlbfs in PV guests" has been added to the 4.5-stable tree

[gregkh]

This is a note to let you know that I've just added the patch titled

x86/mm/xen: Suppress hugetlbfs in PV guests

to the 4.5-stable tree which can be found at:

http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
 x86-mm-xen-suppress-hugetlbfs-in-pv-guests.patch
and it can be found in the queue-4.5 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let  know about it.


From 103f6112f253017d7062cd74d17f4a514ed4485c Mon Sep 17 00:00:00 2001
From: Jan Beulich 
Date: Thu, 21 Apr 2016 00:27:04 -0600
Subject: x86/mm/xen: Suppress hugetlbfs in PV guests

From: Jan Beulich 

commit 103f6112f253017d7062cd74d17f4a514ed4485c upstream.

Huge pages are not normally available to PV guests. Not suppressing
hugetlbfs use results in an endless loop of page faults when user mode
code tries to access a hugetlbfs mapped area (since the hypervisor
denies such PTEs to be created, but error indications can't be
propagated out of xen_set_pte_at(), just like for various of its
siblings), and - once killed in an oops like this:

  kernel BUG at .../fs/hugetlbfs/inode.c:428!
  invalid opcode:  [#1] SMP
  ...
  RIP: e030:[]  [] 
remove_inode_hugepages+0x25b/0x320
  ...
  Call Trace:
   [] hugetlbfs_evict_inode+0x15/0x40
   [] evict+0xbd/0x1b0
   [] __dentry_kill+0x19a/0x1f0
   [] dput+0x1fe/0x220
   [] __fput+0x155/0x200
   [] task_work_run+0x60/0xa0
   [] do_exit+0x160/0x400
   [] do_group_exit+0x3b/0xa0
   [] get_signal+0x1ed/0x470
   [] do_signal+0x14/0x110
   [] prepare_exit_to_usermode+0xe9/0xf0
   [] retint_user+0x8/0x13

This is CVE-2016-3961 / XSA-174.

Reported-by: Vitaly Kuznetsov 
Signed-off-by: Jan Beulich 
Cc: Andrew Morton 
Cc: Andy Lutomirski 
Cc: Boris Ostrovsky 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: David Vrabel 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Juergen Gross 
Cc: Linus Torvalds 
Cc: Luis R. Rodriguez 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: Toshi Kani 
Cc: xen-devel 
Link: http://lkml.kernel.org/r/57188ed80278000e4...@prv-mh.provo.novell.com
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/include/asm/hugetlb.h |1 +
 1 file changed, 1 insertion(+)

--- a/arch/x86/include/asm/hugetlb.h
+++ b/arch/x86/include/asm/hugetlb.h
@@ -4,6 +4,7 @@
 #include 
 #include 
 
+#define hugepages_supported() cpu_has_pse
 
 static inline int is_hugepage_only_range(struct mm_struct *mm,
 unsigned long addr,


Patches currently in stable-queue which might be from jbeul...@suse.com are

queue-4.5/x86-mm-xen-suppress-hugetlbfs-in-pv-guests.patch

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] Patch "x86/cpu: Fix SMAP check in PVOPS environments" has been added to the 4.1-stable tree

[gregkh]

This is a note to let you know that I've just added the patch titled

x86/cpu: Fix SMAP check in PVOPS environments

to the 4.1-stable tree which can be found at:

http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
 x86-cpu-fix-smap-check-in-pvops-environments.patch
and it can be found in the queue-4.1 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let  know about it.


>From 581b7f158fe0383b492acd1ce3fb4e99d4e57808 Mon Sep 17 00:00:00 2001
From: Andrew Cooper 
Date: Wed, 3 Jun 2015 10:31:14 +0100
Subject: x86/cpu: Fix SMAP check in PVOPS environments

From: Andrew Cooper 

commit 581b7f158fe0383b492acd1ce3fb4e99d4e57808 upstream.

There appears to be no formal statement of what pv_irq_ops.save_fl() is
supposed to return precisely.  Native returns the full flags, while lguest and
Xen only return the Interrupt Flag, and both have comments by the
implementations stating that only the Interrupt Flag is looked at.  This may
have been true when initially implemented, but no longer is.

To make matters worse, the Xen PVOP leaves the upper bits undefined, making
the BUG_ON() undefined behaviour.  Experimentally, this now trips for 32bit PV
guests on Broadwell hardware.  The BUG_ON() is consistent for an individual
build, but not consistent for all builds.  It has also been a sitting timebomb
since SMAP support was introduced.

Use native_save_fl() instead, which will obtain an accurate view of the AC
flag.

Signed-off-by: Andrew Cooper 
Reviewed-by: David Vrabel 
Tested-by: Rusty Russell 
Cc: Rusty Russell 
Cc: Konrad Rzeszutek Wilk 
Cc: Boris Ostrovsky 
Cc: 
Cc: Xen-devel 
Link: 
http://lkml.kernel.org/r/1433323874-6927-1-git-send-email-andrew.coop...@citrix.com
Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/kernel/cpu/common.c |3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -291,10 +291,9 @@ __setup("nosmap", setup_disable_smap);
 
 static __always_inline void setup_smap(struct cpuinfo_x86 *c)
 {
-   unsigned long eflags;
+   unsigned long eflags = native_save_fl();
 
/* This should have been cleared long ago */
-   raw_local_save_flags(eflags);
BUG_ON(eflags & X86_EFLAGS_AC);
 
if (cpu_has(c, X86_FEATURE_SMAP)) {


Patches currently in stable-queue which might be from andrew.coop...@citrix.com 
are

queue-4.1/x86-cpu-fix-smap-check-in-pvops-environments.patch

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] Patch "x86/cpu: Fix SMAP check in PVOPS environments" has been added to the 3.10-stable tree

[gregkh]

This is a note to let you know that I've just added the patch titled

x86/cpu: Fix SMAP check in PVOPS environments

to the 3.10-stable tree which can be found at:

http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
 x86-cpu-fix-smap-check-in-pvops-environments.patch
and it can be found in the queue-3.10 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let  know about it.


>From 581b7f158fe0383b492acd1ce3fb4e99d4e57808 Mon Sep 17 00:00:00 2001
From: Andrew Cooper 
Date: Wed, 3 Jun 2015 10:31:14 +0100
Subject: x86/cpu: Fix SMAP check in PVOPS environments

From: Andrew Cooper 

commit 581b7f158fe0383b492acd1ce3fb4e99d4e57808 upstream.

There appears to be no formal statement of what pv_irq_ops.save_fl() is
supposed to return precisely.  Native returns the full flags, while lguest and
Xen only return the Interrupt Flag, and both have comments by the
implementations stating that only the Interrupt Flag is looked at.  This may
have been true when initially implemented, but no longer is.

To make matters worse, the Xen PVOP leaves the upper bits undefined, making
the BUG_ON() undefined behaviour.  Experimentally, this now trips for 32bit PV
guests on Broadwell hardware.  The BUG_ON() is consistent for an individual
build, but not consistent for all builds.  It has also been a sitting timebomb
since SMAP support was introduced.

Use native_save_fl() instead, which will obtain an accurate view of the AC
flag.

Signed-off-by: Andrew Cooper 
Reviewed-by: David Vrabel 
Tested-by: Rusty Russell 
Cc: Rusty Russell 
Cc: Konrad Rzeszutek Wilk 
Cc: Boris Ostrovsky 
Cc: 
Cc: Xen-devel 
Link: 
http://lkml.kernel.org/r/1433323874-6927-1-git-send-email-andrew.coop...@citrix.com
Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/kernel/cpu/common.c |3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -280,10 +280,9 @@ __setup("nosmap", setup_disable_smap);
 
 static __always_inline void setup_smap(struct cpuinfo_x86 *c)
 {
-   unsigned long eflags;
+   unsigned long eflags = native_save_fl();
 
/* This should have been cleared long ago */
-   raw_local_save_flags(eflags);
BUG_ON(eflags & X86_EFLAGS_AC);
 
if (cpu_has(c, X86_FEATURE_SMAP)) {


Patches currently in stable-queue which might be from andrew.coop...@citrix.com 
are

queue-3.10/x86-cpu-fix-smap-check-in-pvops-environments.patch

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] Patch "x86/cpu: Fix SMAP check in PVOPS environments" has been added to the 3.14-stable tree

[gregkh]

This is a note to let you know that I've just added the patch titled

x86/cpu: Fix SMAP check in PVOPS environments

to the 3.14-stable tree which can be found at:

http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
 x86-cpu-fix-smap-check-in-pvops-environments.patch
and it can be found in the queue-3.14 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let  know about it.


>From 581b7f158fe0383b492acd1ce3fb4e99d4e57808 Mon Sep 17 00:00:00 2001
From: Andrew Cooper 
Date: Wed, 3 Jun 2015 10:31:14 +0100
Subject: x86/cpu: Fix SMAP check in PVOPS environments

From: Andrew Cooper 

commit 581b7f158fe0383b492acd1ce3fb4e99d4e57808 upstream.

There appears to be no formal statement of what pv_irq_ops.save_fl() is
supposed to return precisely.  Native returns the full flags, while lguest and
Xen only return the Interrupt Flag, and both have comments by the
implementations stating that only the Interrupt Flag is looked at.  This may
have been true when initially implemented, but no longer is.

To make matters worse, the Xen PVOP leaves the upper bits undefined, making
the BUG_ON() undefined behaviour.  Experimentally, this now trips for 32bit PV
guests on Broadwell hardware.  The BUG_ON() is consistent for an individual
build, but not consistent for all builds.  It has also been a sitting timebomb
since SMAP support was introduced.

Use native_save_fl() instead, which will obtain an accurate view of the AC
flag.

Signed-off-by: Andrew Cooper 
Reviewed-by: David Vrabel 
Tested-by: Rusty Russell 
Cc: Rusty Russell 
Cc: Konrad Rzeszutek Wilk 
Cc: Boris Ostrovsky 
Cc: 
Cc: Xen-devel 
Link: 
http://lkml.kernel.org/r/1433323874-6927-1-git-send-email-andrew.coop...@citrix.com
Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/kernel/cpu/common.c |3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -280,10 +280,9 @@ __setup("nosmap", setup_disable_smap);
 
 static __always_inline void setup_smap(struct cpuinfo_x86 *c)
 {
-   unsigned long eflags;
+   unsigned long eflags = native_save_fl();
 
/* This should have been cleared long ago */
-   raw_local_save_flags(eflags);
BUG_ON(eflags & X86_EFLAGS_AC);
 
if (cpu_has(c, X86_FEATURE_SMAP)) {


Patches currently in stable-queue which might be from andrew.coop...@citrix.com 
are

queue-3.14/x86-cpu-fix-smap-check-in-pvops-environments.patch

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] Patch "x86/cpu: Fix SMAP check in PVOPS environments" has been added to the 4.2-stable tree

[gregkh]

This is a note to let you know that I've just added the patch titled

x86/cpu: Fix SMAP check in PVOPS environments

to the 4.2-stable tree which can be found at:

http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
 x86-cpu-fix-smap-check-in-pvops-environments.patch
and it can be found in the queue-4.2 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let  know about it.


>From 581b7f158fe0383b492acd1ce3fb4e99d4e57808 Mon Sep 17 00:00:00 2001
From: Andrew Cooper 
Date: Wed, 3 Jun 2015 10:31:14 +0100
Subject: x86/cpu: Fix SMAP check in PVOPS environments

From: Andrew Cooper 

commit 581b7f158fe0383b492acd1ce3fb4e99d4e57808 upstream.

There appears to be no formal statement of what pv_irq_ops.save_fl() is
supposed to return precisely.  Native returns the full flags, while lguest and
Xen only return the Interrupt Flag, and both have comments by the
implementations stating that only the Interrupt Flag is looked at.  This may
have been true when initially implemented, but no longer is.

To make matters worse, the Xen PVOP leaves the upper bits undefined, making
the BUG_ON() undefined behaviour.  Experimentally, this now trips for 32bit PV
guests on Broadwell hardware.  The BUG_ON() is consistent for an individual
build, but not consistent for all builds.  It has also been a sitting timebomb
since SMAP support was introduced.

Use native_save_fl() instead, which will obtain an accurate view of the AC
flag.

Signed-off-by: Andrew Cooper 
Reviewed-by: David Vrabel 
Tested-by: Rusty Russell 
Cc: Rusty Russell 
Cc: Konrad Rzeszutek Wilk 
Cc: Boris Ostrovsky 
Cc: 
Cc: Xen-devel 
Link: 
http://lkml.kernel.org/r/1433323874-6927-1-git-send-email-andrew.coop...@citrix.com
Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/kernel/cpu/common.c |3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -272,10 +272,9 @@ __setup("nosmap", setup_disable_smap);
 
 static __always_inline void setup_smap(struct cpuinfo_x86 *c)
 {
-   unsigned long eflags;
+   unsigned long eflags = native_save_fl();
 
/* This should have been cleared long ago */
-   raw_local_save_flags(eflags);
BUG_ON(eflags & X86_EFLAGS_AC);
 
if (cpu_has(c, X86_FEATURE_SMAP)) {


Patches currently in stable-queue which might be from andrew.coop...@citrix.com 
are

queue-4.2/x86-cpu-fix-smap-check-in-pvops-environments.patch

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] Patch "x86/cpu: Fix SMAP check in PVOPS environments" has been added to the 4.3-stable tree

[gregkh]

This is a note to let you know that I've just added the patch titled

x86/cpu: Fix SMAP check in PVOPS environments

to the 4.3-stable tree which can be found at:

http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
 x86-cpu-fix-smap-check-in-pvops-environments.patch
and it can be found in the queue-4.3 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let  know about it.


>From 581b7f158fe0383b492acd1ce3fb4e99d4e57808 Mon Sep 17 00:00:00 2001
From: Andrew Cooper 
Date: Wed, 3 Jun 2015 10:31:14 +0100
Subject: x86/cpu: Fix SMAP check in PVOPS environments

From: Andrew Cooper 

commit 581b7f158fe0383b492acd1ce3fb4e99d4e57808 upstream.

There appears to be no formal statement of what pv_irq_ops.save_fl() is
supposed to return precisely.  Native returns the full flags, while lguest and
Xen only return the Interrupt Flag, and both have comments by the
implementations stating that only the Interrupt Flag is looked at.  This may
have been true when initially implemented, but no longer is.

To make matters worse, the Xen PVOP leaves the upper bits undefined, making
the BUG_ON() undefined behaviour.  Experimentally, this now trips for 32bit PV
guests on Broadwell hardware.  The BUG_ON() is consistent for an individual
build, but not consistent for all builds.  It has also been a sitting timebomb
since SMAP support was introduced.

Use native_save_fl() instead, which will obtain an accurate view of the AC
flag.

Signed-off-by: Andrew Cooper 
Reviewed-by: David Vrabel 
Tested-by: Rusty Russell 
Cc: Rusty Russell 
Cc: Konrad Rzeszutek Wilk 
Cc: Boris Ostrovsky 
Cc: 
Cc: Xen-devel 
Link: 
http://lkml.kernel.org/r/1433323874-6927-1-git-send-email-andrew.coop...@citrix.com
Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/kernel/cpu/common.c |3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -273,10 +273,9 @@ __setup("nosmap", setup_disable_smap);
 
 static __always_inline void setup_smap(struct cpuinfo_x86 *c)
 {
-   unsigned long eflags;
+   unsigned long eflags = native_save_fl();
 
/* This should have been cleared long ago */
-   raw_local_save_flags(eflags);
BUG_ON(eflags & X86_EFLAGS_AC);
 
if (cpu_has(c, X86_FEATURE_SMAP)) {


Patches currently in stable-queue which might be from andrew.coop...@citrix.com 
are

queue-4.3/x86-cpu-fix-smap-check-in-pvops-environments.patch

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] Patch "x86/ldt: Make modify_ldt synchronous" has been added to the 4.1-stable tree

[gregkh]

This is a note to let you know that I've just added the patch titled

x86/ldt: Make modify_ldt synchronous

to the 4.1-stable tree which can be found at:

http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
 x86-ldt-make-modify_ldt-synchronous.patch
and it can be found in the queue-4.1 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let  know about it.


>From 37868fe113ff2ba814b3b4eb12df214df555f8dc Mon Sep 17 00:00:00 2001
From: Andy Lutomirski 
Date: Thu, 30 Jul 2015 14:31:32 -0700
Subject: x86/ldt: Make modify_ldt synchronous

From: Andy Lutomirski 

commit 37868fe113ff2ba814b3b4eb12df214df555f8dc upstream.

modify_ldt() has questionable locking and does not synchronize
threads.  Improve it: redesign the locking and synchronize all
threads' LDTs using an IPI on all modifications.

This will dramatically slow down modify_ldt in multithreaded
programs, but there shouldn't be any multithreaded programs that
care about modify_ldt's performance in the first place.

This fixes some fallout from the CVE-2015-5157 fixes.

Signed-off-by: Andy Lutomirski 
Reviewed-by: Borislav Petkov 
Cc: Andrew Cooper 
Cc: Andy Lutomirski 
Cc: Boris Ostrovsky 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Sasha Levin 
Cc: Steven Rostedt 
Cc: Thomas Gleixner 
Cc: secur...@kernel.org 
Cc: xen-devel 
Link: 
http://lkml.kernel.org/r/4c6978476782160600471bd865b318db34c7b628.1438291540.git.l...@kernel.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/include/asm/desc.h|   15 --
 arch/x86/include/asm/mmu.h |3 
 arch/x86/include/asm/mmu_context.h |   54 ++-
 arch/x86/kernel/cpu/common.c   |4 
 arch/x86/kernel/cpu/perf_event.c   |   12 +
 arch/x86/kernel/ldt.c  |  264 -
 arch/x86/kernel/process_64.c   |4 
 arch/x86/kernel/step.c |6 
 arch/x86/power/cpu.c   |3 
 9 files changed, 211 insertions(+), 154 deletions(-)

--- a/arch/x86/include/asm/desc.h
+++ b/arch/x86/include/asm/desc.h
@@ -280,21 +280,6 @@ static inline void clear_LDT(void)
set_ldt(NULL, 0);
 }
 
-/*
- * load one particular LDT into the current CPU
- */
-static inline void load_LDT_nolock(mm_context_t *pc)
-{
-   set_ldt(pc->ldt, pc->size);
-}
-
-static inline void load_LDT(mm_context_t *pc)
-{
-   preempt_disable();
-   load_LDT_nolock(pc);
-   preempt_enable();
-}
-
 static inline unsigned long get_desc_base(const struct desc_struct *desc)
 {
return (unsigned)(desc->base0 | ((desc->base1) << 16) | ((desc->base2) 
<< 24));
--- a/arch/x86/include/asm/mmu.h
+++ b/arch/x86/include/asm/mmu.h
@@ -9,8 +9,7 @@
  * we put the segment information here.
  */
 typedef struct {
-   void *ldt;
-   int size;
+   struct ldt_struct *ldt;
 
 #ifdef CONFIG_X86_64
/* True if mm supports a task running in 32 bit compatibility mode. */
--- a/arch/x86/include/asm/mmu_context.h
+++ b/arch/x86/include/asm/mmu_context.h
@@ -34,6 +34,50 @@ static inline void load_mm_cr4(struct mm
 #endif
 
 /*
+ * ldt_structs can be allocated, used, and freed, but they are never
+ * modified while live.
+ */
+struct ldt_struct {
+   /*
+* Xen requires page-aligned LDTs with special permissions.  This is
+* needed to prevent us from installing evil descriptors such as
+* call gates.  On native, we could merge the ldt_struct and LDT
+* allocations, but it's not worth trying to optimize.
+*/
+   struct desc_struct *entries;
+   int size;
+};
+
+static inline void load_mm_ldt(struct mm_struct *mm)
+{
+   struct ldt_struct *ldt;
+
+   /* lockless_dereference synchronizes with smp_store_release */
+   ldt = lockless_dereference(mm->context.ldt);
+
+   /*
+* Any change to mm->context.ldt is followed by an IPI to all
+* CPUs with the mm active.  The LDT will not be freed until
+* after the IPI is handled by all such CPUs.  This means that,
+* if the ldt_struct changes before we return, the values we see
+* will be safe, and the new values will be loaded before we run
+* any user code.
+*
+* NB: don't try to convert this to use RCU without extreme care.
+* We would still 

[Xen-devel] Patch x86/ldt: Make modify_ldt synchronous has been added to the 4.1-stable tree

[gregkh]

This is a note to let you know that I've just added the patch titled

x86/ldt: Make modify_ldt synchronous

to the 4.1-stable tree which can be found at:

http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
 x86-ldt-make-modify_ldt-synchronous.patch
and it can be found in the queue-4.1 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let sta...@vger.kernel.org know about it.


From 37868fe113ff2ba814b3b4eb12df214df555f8dc Mon Sep 17 00:00:00 2001
From: Andy Lutomirski l...@kernel.org
Date: Thu, 30 Jul 2015 14:31:32 -0700
Subject: x86/ldt: Make modify_ldt synchronous

From: Andy Lutomirski l...@kernel.org

commit 37868fe113ff2ba814b3b4eb12df214df555f8dc upstream.

modify_ldt() has questionable locking and does not synchronize
threads.  Improve it: redesign the locking and synchronize all
threads' LDTs using an IPI on all modifications.

This will dramatically slow down modify_ldt in multithreaded
programs, but there shouldn't be any multithreaded programs that
care about modify_ldt's performance in the first place.

This fixes some fallout from the CVE-2015-5157 fixes.

Signed-off-by: Andy Lutomirski l...@kernel.org
Reviewed-by: Borislav Petkov b...@suse.de
Cc: Andrew Cooper andrew.coop...@citrix.com
Cc: Andy Lutomirski l...@amacapital.net
Cc: Boris Ostrovsky boris.ostrov...@oracle.com
Cc: Borislav Petkov b...@alien8.de
Cc: Brian Gerst brge...@gmail.com
Cc: Denys Vlasenko dvlas...@redhat.com
Cc: H. Peter Anvin h...@zytor.com
Cc: Jan Beulich jbeul...@suse.com
Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Cc: Linus Torvalds torva...@linux-foundation.org
Cc: Peter Zijlstra pet...@infradead.org
Cc: Sasha Levin sasha.le...@oracle.com
Cc: Steven Rostedt rost...@goodmis.org
Cc: Thomas Gleixner t...@linutronix.de
Cc: secur...@kernel.org secur...@kernel.org
Cc: xen-devel xen-devel@lists.xen.org
Link: 
http://lkml.kernel.org/r/4c6978476782160600471bd865b318db34c7b628.1438291540.git.l...@kernel.org
Signed-off-by: Ingo Molnar mi...@kernel.org
Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org

---
 arch/x86/include/asm/desc.h|   15 --
 arch/x86/include/asm/mmu.h |3 
 arch/x86/include/asm/mmu_context.h |   54 ++-
 arch/x86/kernel/cpu/common.c   |4 
 arch/x86/kernel/cpu/perf_event.c   |   12 +
 arch/x86/kernel/ldt.c  |  264 -
 arch/x86/kernel/process_64.c   |4 
 arch/x86/kernel/step.c |6 
 arch/x86/power/cpu.c   |3 
 9 files changed, 211 insertions(+), 154 deletions(-)

--- a/arch/x86/include/asm/desc.h
+++ b/arch/x86/include/asm/desc.h
@@ -280,21 +280,6 @@ static inline void clear_LDT(void)
set_ldt(NULL, 0);
 }
 
-/*
- * load one particular LDT into the current CPU
- */
-static inline void load_LDT_nolock(mm_context_t *pc)
-{
-   set_ldt(pc-ldt, pc-size);
-}
-
-static inline void load_LDT(mm_context_t *pc)
-{
-   preempt_disable();
-   load_LDT_nolock(pc);
-   preempt_enable();
-}
-
 static inline unsigned long get_desc_base(const struct desc_struct *desc)
 {
return (unsigned)(desc-base0 | ((desc-base1)  16) | ((desc-base2) 
 24));
--- a/arch/x86/include/asm/mmu.h
+++ b/arch/x86/include/asm/mmu.h
@@ -9,8 +9,7 @@
  * we put the segment information here.
  */
 typedef struct {
-   void *ldt;
-   int size;
+   struct ldt_struct *ldt;
 
 #ifdef CONFIG_X86_64
/* True if mm supports a task running in 32 bit compatibility mode. */
--- a/arch/x86/include/asm/mmu_context.h
+++ b/arch/x86/include/asm/mmu_context.h
@@ -34,6 +34,50 @@ static inline void load_mm_cr4(struct mm
 #endif
 
 /*
+ * ldt_structs can be allocated, used, and freed, but they are never
+ * modified while live.
+ */
+struct ldt_struct {
+   /*
+* Xen requires page-aligned LDTs with special permissions.  This is
+* needed to prevent us from installing evil descriptors such as
+* call gates.  On native, we could merge the ldt_struct and LDT
+* allocations, but it's not worth trying to optimize.
+*/
+   struct desc_struct *entries;
+   int size;
+};
+
+static inline void load_mm_ldt(struct mm_struct *mm)
+{
+   struct ldt_struct *ldt;
+
+   /* lockless_dereference synchronizes with smp_store_release */
+   ldt = lockless_dereference(mm-context.ldt);
+
+   /*
+* Any change to mm-context.ldt is followed by an IPI to all
+* CPUs with the mm active.  The LDT will not be freed until
+* after the IPI is handled by all such CPUs.  This means that,
+* if the ldt_struct changes before we return, the values we see
+* will be safe, and the new values will be loaded before we run
+* any user code.
+*
+* NB: don't try to convert this to use RCU without extreme care.
+* We would still need IRQs off, because we don't want to change
+* 

[Xen-devel] Patch x86/xen: Probe target addresses in set_aliased_prot() before the hypercall has been added to the 4.1-stable tree

[gregkh]

This is a note to let you know that I've just added the patch titled

x86/xen: Probe target addresses in set_aliased_prot() before the hypercall

to the 4.1-stable tree which can be found at:

http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
 
x86-xen-probe-target-addresses-in-set_aliased_prot-before-the-hypercall.patch
and it can be found in the queue-4.1 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let sta...@vger.kernel.org know about it.


From aa1acff356bbedfd03b544051f5b371746735d89 Mon Sep 17 00:00:00 2001
From: Andy Lutomirski l...@kernel.org
Date: Thu, 30 Jul 2015 14:31:31 -0700
Subject: x86/xen: Probe target addresses in set_aliased_prot() before the 
hypercall

From: Andy Lutomirski l...@kernel.org

commit aa1acff356bbedfd03b544051f5b371746735d89 upstream.

The update_va_mapping hypercall can fail if the VA isn't present
in the guest's page tables.  Under certain loads, this can
result in an OOPS when the target address is in unpopulated vmap
space.

While we're at it, add comments to help explain what's going on.

This isn't a great long-term fix.  This code should probably be
changed to use something like set_memory_ro.

Signed-off-by: Andy Lutomirski l...@kernel.org
Cc: Andrew Cooper andrew.coop...@citrix.com
Cc: Andy Lutomirski l...@amacapital.net
Cc: Boris Ostrovsky boris.ostrov...@oracle.com
Cc: Borislav Petkov b...@alien8.de
Cc: Brian Gerst brge...@gmail.com
Cc: David Vrabel dvra...@cantab.net
Cc: Denys Vlasenko dvlas...@redhat.com
Cc: H. Peter Anvin h...@zytor.com
Cc: Jan Beulich jbeul...@suse.com
Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Cc: Linus Torvalds torva...@linux-foundation.org
Cc: Peter Zijlstra pet...@infradead.org
Cc: Sasha Levin sasha.le...@oracle.com
Cc: Steven Rostedt rost...@goodmis.org
Cc: Thomas Gleixner t...@linutronix.de
Cc: secur...@kernel.org secur...@kernel.org
Cc: xen-devel xen-devel@lists.xen.org
Link: 
http://lkml.kernel.org/r/0b0e55b995cda11e7829f140b833ef932fcabe3a.1438291540.git.l...@kernel.org
Signed-off-by: Ingo Molnar mi...@kernel.org
Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org

---
 arch/x86/xen/enlighten.c |   40 
 1 file changed, 40 insertions(+)

--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -483,6 +483,7 @@ static void set_aliased_prot(void *v, pg
pte_t pte;
unsigned long pfn;
struct page *page;
+   unsigned char dummy;
 
ptep = lookup_address((unsigned long)v, level);
BUG_ON(ptep == NULL);
@@ -492,6 +493,32 @@ static void set_aliased_prot(void *v, pg
 
pte = pfn_pte(pfn, prot);
 
+   /*
+* Careful: update_va_mapping() will fail if the virtual address
+* we're poking isn't populated in the page tables.  We don't
+* need to worry about the direct map (that's always in the page
+* tables), but we need to be careful about vmap space.  In
+* particular, the top level page table can lazily propagate
+* entries between processes, so if we've switched mms since we
+* vmapped the target in the first place, we might not have the
+* top-level page table entry populated.
+*
+* We disable preemption because we want the same mm active when
+* we probe the target and when we issue the hypercall.  We'll
+* have the same nominal mm, but if we're a kernel thread, lazy
+* mm dropping could change our pgd.
+*
+* Out of an abundance of caution, this uses __get_user() to fault
+* in the target address just in case there's some obscure case
+* in which the target address isn't readable.
+*/
+
+   preempt_disable();
+
+   pagefault_disable();/* Avoid warnings due to being atomic. */
+   __get_user(dummy, (unsigned char __user __force *)v);
+   pagefault_enable();
+
if (HYPERVISOR_update_va_mapping((unsigned long)v, pte, 0))
BUG();
 
@@ -503,6 +530,8 @@ static void set_aliased_prot(void *v, pg
BUG();
} else
kmap_flush_unused();
+
+   preempt_enable();
 }
 
 static void xen_alloc_ldt(struct desc_struct *ldt, unsigned entries)
@@ -510,6 +539,17 @@ static void xen_alloc_ldt(struct desc_st
const unsigned entries_per_page = PAGE_SIZE / LDT_ENTRY_SIZE;
int i;
 
+   /*
+* We need to mark the all aliases of the LDT pages RO.  We
+* don't need to call vm_flush_aliases(), though, since that's
+* only responsible for flushing aliases out the TLBs, not the
+* page tables, and Xen will flush the TLB for us if needed.
+*
+* To avoid confusing future readers: none of this is necessary
+* to load the LDT.  The hypervisor only checks this when the
+* LDT is faulted in due to subsequent descriptor access.
+ 

[Xen-devel] Patch x86/xen: Probe target addresses in set_aliased_prot() before the hypercall has been added to the 3.14-stable tree

[gregkh]

This is a note to let you know that I've just added the patch titled

x86/xen: Probe target addresses in set_aliased_prot() before the hypercall

to the 3.14-stable tree which can be found at:

http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
 
x86-xen-probe-target-addresses-in-set_aliased_prot-before-the-hypercall.patch
and it can be found in the queue-3.14 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let sta...@vger.kernel.org know about it.


From aa1acff356bbedfd03b544051f5b371746735d89 Mon Sep 17 00:00:00 2001
From: Andy Lutomirski l...@kernel.org
Date: Thu, 30 Jul 2015 14:31:31 -0700
Subject: x86/xen: Probe target addresses in set_aliased_prot() before the 
hypercall

From: Andy Lutomirski l...@kernel.org

commit aa1acff356bbedfd03b544051f5b371746735d89 upstream.

The update_va_mapping hypercall can fail if the VA isn't present
in the guest's page tables.  Under certain loads, this can
result in an OOPS when the target address is in unpopulated vmap
space.

While we're at it, add comments to help explain what's going on.

This isn't a great long-term fix.  This code should probably be
changed to use something like set_memory_ro.

Signed-off-by: Andy Lutomirski l...@kernel.org
Cc: Andrew Cooper andrew.coop...@citrix.com
Cc: Andy Lutomirski l...@amacapital.net
Cc: Boris Ostrovsky boris.ostrov...@oracle.com
Cc: Borislav Petkov b...@alien8.de
Cc: Brian Gerst brge...@gmail.com
Cc: David Vrabel dvra...@cantab.net
Cc: Denys Vlasenko dvlas...@redhat.com
Cc: H. Peter Anvin h...@zytor.com
Cc: Jan Beulich jbeul...@suse.com
Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Cc: Linus Torvalds torva...@linux-foundation.org
Cc: Peter Zijlstra pet...@infradead.org
Cc: Sasha Levin sasha.le...@oracle.com
Cc: Steven Rostedt rost...@goodmis.org
Cc: Thomas Gleixner t...@linutronix.de
Cc: secur...@kernel.org secur...@kernel.org
Cc: xen-devel xen-devel@lists.xen.org
Link: 
http://lkml.kernel.org/r/0b0e55b995cda11e7829f140b833ef932fcabe3a.1438291540.git.l...@kernel.org
Signed-off-by: Ingo Molnar mi...@kernel.org
Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org

---
 arch/x86/xen/enlighten.c |   40 
 1 file changed, 40 insertions(+)

--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -481,6 +481,7 @@ static void set_aliased_prot(void *v, pg
pte_t pte;
unsigned long pfn;
struct page *page;
+   unsigned char dummy;
 
ptep = lookup_address((unsigned long)v, level);
BUG_ON(ptep == NULL);
@@ -490,6 +491,32 @@ static void set_aliased_prot(void *v, pg
 
pte = pfn_pte(pfn, prot);
 
+   /*
+* Careful: update_va_mapping() will fail if the virtual address
+* we're poking isn't populated in the page tables.  We don't
+* need to worry about the direct map (that's always in the page
+* tables), but we need to be careful about vmap space.  In
+* particular, the top level page table can lazily propagate
+* entries between processes, so if we've switched mms since we
+* vmapped the target in the first place, we might not have the
+* top-level page table entry populated.
+*
+* We disable preemption because we want the same mm active when
+* we probe the target and when we issue the hypercall.  We'll
+* have the same nominal mm, but if we're a kernel thread, lazy
+* mm dropping could change our pgd.
+*
+* Out of an abundance of caution, this uses __get_user() to fault
+* in the target address just in case there's some obscure case
+* in which the target address isn't readable.
+*/
+
+   preempt_disable();
+
+   pagefault_disable();/* Avoid warnings due to being atomic. */
+   __get_user(dummy, (unsigned char __user __force *)v);
+   pagefault_enable();
+
if (HYPERVISOR_update_va_mapping((unsigned long)v, pte, 0))
BUG();
 
@@ -501,6 +528,8 @@ static void set_aliased_prot(void *v, pg
BUG();
} else
kmap_flush_unused();
+
+   preempt_enable();
 }
 
 static void xen_alloc_ldt(struct desc_struct *ldt, unsigned entries)
@@ -508,6 +537,17 @@ static void xen_alloc_ldt(struct desc_st
const unsigned entries_per_page = PAGE_SIZE / LDT_ENTRY_SIZE;
int i;
 
+   /*
+* We need to mark the all aliases of the LDT pages RO.  We
+* don't need to call vm_flush_aliases(), though, since that's
+* only responsible for flushing aliases out the TLBs, not the
+* page tables, and Xen will flush the TLB for us if needed.
+*
+* To avoid confusing future readers: none of this is necessary
+* to load the LDT.  The hypervisor only checks this when the
+* LDT is faulted in due to subsequent descriptor access.

[Xen-devel] Patch x86/xen: Probe target addresses in set_aliased_prot() before the hypercall has been added to the 3.10-stable tree

[gregkh]

This is a note to let you know that I've just added the patch titled

x86/xen: Probe target addresses in set_aliased_prot() before the hypercall

to the 3.10-stable tree which can be found at:

http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
 
x86-xen-probe-target-addresses-in-set_aliased_prot-before-the-hypercall.patch
and it can be found in the queue-3.10 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let sta...@vger.kernel.org know about it.


From aa1acff356bbedfd03b544051f5b371746735d89 Mon Sep 17 00:00:00 2001
From: Andy Lutomirski l...@kernel.org
Date: Thu, 30 Jul 2015 14:31:31 -0700
Subject: x86/xen: Probe target addresses in set_aliased_prot() before the 
hypercall

From: Andy Lutomirski l...@kernel.org

commit aa1acff356bbedfd03b544051f5b371746735d89 upstream.

The update_va_mapping hypercall can fail if the VA isn't present
in the guest's page tables.  Under certain loads, this can
result in an OOPS when the target address is in unpopulated vmap
space.

While we're at it, add comments to help explain what's going on.

This isn't a great long-term fix.  This code should probably be
changed to use something like set_memory_ro.

Signed-off-by: Andy Lutomirski l...@kernel.org
Cc: Andrew Cooper andrew.coop...@citrix.com
Cc: Andy Lutomirski l...@amacapital.net
Cc: Boris Ostrovsky boris.ostrov...@oracle.com
Cc: Borislav Petkov b...@alien8.de
Cc: Brian Gerst brge...@gmail.com
Cc: David Vrabel dvra...@cantab.net
Cc: Denys Vlasenko dvlas...@redhat.com
Cc: H. Peter Anvin h...@zytor.com
Cc: Jan Beulich jbeul...@suse.com
Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Cc: Linus Torvalds torva...@linux-foundation.org
Cc: Peter Zijlstra pet...@infradead.org
Cc: Sasha Levin sasha.le...@oracle.com
Cc: Steven Rostedt rost...@goodmis.org
Cc: Thomas Gleixner t...@linutronix.de
Cc: secur...@kernel.org secur...@kernel.org
Cc: xen-devel xen-devel@lists.xen.org
Link: 
http://lkml.kernel.org/r/0b0e55b995cda11e7829f140b833ef932fcabe3a.1438291540.git.l...@kernel.org
Signed-off-by: Ingo Molnar mi...@kernel.org
Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org

---
 arch/x86/xen/enlighten.c |   40 
 1 file changed, 40 insertions(+)

--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -481,6 +481,7 @@ static void set_aliased_prot(void *v, pg
pte_t pte;
unsigned long pfn;
struct page *page;
+   unsigned char dummy;
 
ptep = lookup_address((unsigned long)v, level);
BUG_ON(ptep == NULL);
@@ -490,6 +491,32 @@ static void set_aliased_prot(void *v, pg
 
pte = pfn_pte(pfn, prot);
 
+   /*
+* Careful: update_va_mapping() will fail if the virtual address
+* we're poking isn't populated in the page tables.  We don't
+* need to worry about the direct map (that's always in the page
+* tables), but we need to be careful about vmap space.  In
+* particular, the top level page table can lazily propagate
+* entries between processes, so if we've switched mms since we
+* vmapped the target in the first place, we might not have the
+* top-level page table entry populated.
+*
+* We disable preemption because we want the same mm active when
+* we probe the target and when we issue the hypercall.  We'll
+* have the same nominal mm, but if we're a kernel thread, lazy
+* mm dropping could change our pgd.
+*
+* Out of an abundance of caution, this uses __get_user() to fault
+* in the target address just in case there's some obscure case
+* in which the target address isn't readable.
+*/
+
+   preempt_disable();
+
+   pagefault_disable();/* Avoid warnings due to being atomic. */
+   __get_user(dummy, (unsigned char __user __force *)v);
+   pagefault_enable();
+
if (HYPERVISOR_update_va_mapping((unsigned long)v, pte, 0))
BUG();
 
@@ -501,6 +528,8 @@ static void set_aliased_prot(void *v, pg
BUG();
} else
kmap_flush_unused();
+
+   preempt_enable();
 }
 
 static void xen_alloc_ldt(struct desc_struct *ldt, unsigned entries)
@@ -508,6 +537,17 @@ static void xen_alloc_ldt(struct desc_st
const unsigned entries_per_page = PAGE_SIZE / LDT_ENTRY_SIZE;
int i;
 
+   /*
+* We need to mark the all aliases of the LDT pages RO.  We
+* don't need to call vm_flush_aliases(), though, since that's
+* only responsible for flushing aliases out the TLBs, not the
+* page tables, and Xen will flush the TLB for us if needed.
+*
+* To avoid confusing future readers: none of this is necessary
+* to load the LDT.  The hypervisor only checks this when the
+* LDT is faulted in due to subsequent descriptor access.