--- /dev/null
+From 5accd17d0eb523350c9ef754d655e379c9bb93b3 Mon Sep 17 00:00:00 2001
+From: Robin Murphy <robin.murphy@arm.com>
+Date: Thu, 22 Oct 2015 15:41:52 +0100
+Subject: arm64: Fix compat register mappings
+
+From: Robin Murphy <robin.murphy@arm.com>
+
+commit 5accd17d0eb523350c9ef754d655e379c9bb93b3 upstream.
+
+For reasons not entirely apparent, but now enshrined in history, the
+architectural mapping of AArch32 banked registers to AArch64 registers
+actually orders SP_<mode> and LR_<mode> backwards compared to the
+intuitive r13/r14 order, for all modes except FIQ.
+
+Fix the compat_<reg>_<mode> macros accordingly, in the hope of avoiding
+subtle bugs with KVM and AArch32 guests.
+
+Signed-off-by: Robin Murphy <robin.murphy@arm.com>
+Acked-by: Will Deacon <will.deacon@arm.com>
+Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/arm64/include/asm/ptrace.h | 16 ++++++++--------
+ 1 file changed, 8 insertions(+), 8 deletions(-)
+
+--- a/arch/arm64/include/asm/ptrace.h
++++ b/arch/arm64/include/asm/ptrace.h
+@@ -70,14 +70,14 @@
+ #define compat_sp regs[13]
+ #define compat_lr regs[14]
+ #define compat_sp_hyp regs[15]
+-#define compat_sp_irq regs[16]
+-#define compat_lr_irq regs[17]
+-#define compat_sp_svc regs[18]
+-#define compat_lr_svc regs[19]
+-#define compat_sp_abt regs[20]
+-#define compat_lr_abt regs[21]
+-#define compat_sp_und regs[22]
+-#define compat_lr_und regs[23]
++#define compat_lr_irq regs[16]
++#define compat_sp_irq regs[17]
++#define compat_lr_svc regs[18]
++#define compat_sp_svc regs[19]
++#define compat_lr_abt regs[20]
++#define compat_sp_abt regs[21]
++#define compat_lr_und regs[22]
++#define compat_sp_und regs[23]
+ #define compat_r8_fiq regs[24]
+ #define compat_r9_fiq regs[25]
+ #define compat_r10_fiq regs[26]
--- /dev/null
+From 660f0fc07d21114549c1862e67e78b1cf0c90c29 Mon Sep 17 00:00:00 2001
+From: David Herrmann <dh.herrmann@gmail.com>
+Date: Mon, 7 Sep 2015 12:05:41 +0200
+Subject: Bluetooth: hidp: fix device disconnect on idle timeout
+
+From: David Herrmann <dh.herrmann@gmail.com>
+
+commit 660f0fc07d21114549c1862e67e78b1cf0c90c29 upstream.
+
+The HIDP specs define an idle-timeout which automatically disconnects a
+device. This has always been implemented in the HIDP layer and forced a
+synchronous shutdown of the hidp-scheduler. This works just fine, but
+lacks a forced disconnect on the underlying l2cap channels. This has been
+broken since:
+
+ commit 5205185d461d5902325e457ca80bd421127b7308
+ Author: David Herrmann <dh.herrmann@gmail.com>
+ Date: Sat Apr 6 20:28:47 2013 +0200
+
+ Bluetooth: hidp: remove old session-management
+
+The old session-management always forced an l2cap error on the ctrl/intr
+channels when shutting down. The new session-management skips this, as we
+don't want to enforce channel policy on the caller. In other words, if
+user-space removes an HIDP device, the underlying channels (which are
+*owned* and *referenced* by user-space) are still left active. User-space
+needs to call shutdown(2) or close(2) to release them.
+
+Unfortunately, this does not work with idle-timeouts. There is no way to
+signal user-space that the HIDP layer has been stopped. The API simply
+does not support any event-passing except for poll(2). Hence, we restore
+old behavior and force EUNATCH on the sockets if the HIDP layer is
+disconnected due to idle-timeouts (behavior of explicit disconnects
+remains unmodified). User-space can still call
+
+ getsockopt(..., SO_ERROR, ...)
+
+..to retrieve the EUNATCH error and clear sk_err. Hence, the channels can
+still be re-used (which nobody does so far, though). Therefore, the API
+still supports the new behavior, but with this patch it's also compatible
+to the old implicit channel shutdown.
+
+Reported-by: Mark Haun <haunma@keteu.org>
+Reported-by: Luiz Augusto von Dentz <luiz.dentz@gmail.com>
+Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
+Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ net/bluetooth/hidp/core.c | 14 ++++++++++++++
+ 1 file changed, 14 insertions(+)
+
+--- a/net/bluetooth/hidp/core.c
++++ b/net/bluetooth/hidp/core.c
+@@ -396,6 +396,20 @@ static void hidp_idle_timeout(unsigned l
+ {
+ struct hidp_session *session = (struct hidp_session *) arg;
+
++ /* The HIDP user-space API only contains calls to add and remove
++ * devices. There is no way to forward events of any kind. Therefore,
++ * we have to forcefully disconnect a device on idle-timeouts. This is
++ * unfortunate and weird API design, but it is spec-compliant and
++ * required for backwards-compatibility. Hence, on idle-timeout, we
++ * signal driver-detach events, so poll() will be woken up with an
++ * error-condition on both sockets.
++ */
++
++ session->intr_sock->sk->sk_err = EUNATCH;
++ session->ctrl_sock->sk->sk_err = EUNATCH;
++ wake_up_interruptible(sk_sleep(session->intr_sock->sk));
++ wake_up_interruptible(sk_sleep(session->ctrl_sock->sk));
++
+ hidp_session_terminate(session);
+ }
+
--- /dev/null
+From 7cecd9ab80f43972c056dc068338f7bcc407b71c Mon Sep 17 00:00:00 2001
+From: Mirza Krak <mirza.krak@hostmobility.com>
+Date: Tue, 10 Nov 2015 14:59:34 +0100
+Subject: can: sja1000: clear interrupts on start
+
+From: Mirza Krak <mirza.krak@hostmobility.com>
+
+commit 7cecd9ab80f43972c056dc068338f7bcc407b71c upstream.
+
+According to SJA1000 data sheet error-warning (EI) interrupt is not
+cleared by setting the controller in to reset-mode.
+
+Then if we have the following case:
+- system is suspended (echo mem > /sys/power/state) and SJA1000 is left
+ in operating state
+- A bus error condition occurs which activates EI interrupt, system is
+ still suspended which means EI interrupt will be not be handled nor
+ cleared.
+
+If the above two events occur, on resume there is no way to return the
+SJA1000 to operating state, except to cycle power to it.
+
+By simply reading the IR register on start we will clear any previous
+conditions that could be present.
+
+Signed-off-by: Mirza Krak <mirza.krak@hostmobility.com>
+Reported-by: Christian Magnusson <Christian.Magnusson@semcon.com>
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/net/can/sja1000/sja1000.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/net/can/sja1000/sja1000.c
++++ b/drivers/net/can/sja1000/sja1000.c
+@@ -184,6 +184,9 @@ static void sja1000_start(struct net_dev
+ priv->write_reg(priv, SJA1000_RXERR, 0x0);
+ priv->read_reg(priv, SJA1000_ECC);
+
++ /* clear interrupt flags */
++ priv->read_reg(priv, SJA1000_IR);
++
+ /* leave reset mode */
+ set_normal_mode(dev);
+ }
--- /dev/null
+From 8ec6d97871f37e4743678ea4a455bd59580aa0f4 Mon Sep 17 00:00:00 2001
+From: Johannes Berg <johannes.berg@intel.com>
+Date: Fri, 28 Aug 2015 10:52:53 +0200
+Subject: mac80211: fix driver RSSI event calculations
+
+From: Johannes Berg <johannes.berg@intel.com>
+
+commit 8ec6d97871f37e4743678ea4a455bd59580aa0f4 upstream.
+
+The ifmgd->ave_beacon_signal value cannot be taken as is for
+comparisons, it must be divided by since it's represented
+like that for better accuracy of the EWMA calculations. This
+would lead to invalid driver RSSI events. Fix the used value.
+
+Fixes: 615f7b9bb1f8 ("mac80211: add driver RSSI threshold events")
+Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ net/mac80211/mlme.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/net/mac80211/mlme.c
++++ b/net/mac80211/mlme.c
+@@ -3074,7 +3074,7 @@ ieee80211_rx_mgmt_beacon(struct ieee8021
+
+ if (ifmgd->rssi_min_thold != ifmgd->rssi_max_thold &&
+ ifmgd->count_beacon_signal >= IEEE80211_SIGNAL_AVE_MIN_COUNT) {
+- int sig = ifmgd->ave_beacon_signal;
++ int sig = ifmgd->ave_beacon_signal / 16;
+ int last_sig = ifmgd->last_ave_beacon_signal;
+
+ /*
--- /dev/null
+From 1f9c6e1bc1ba5f8a10fcd6e99d170954d7c6d382 Mon Sep 17 00:00:00 2001
+From: Dan Carpenter <dan.carpenter@oracle.com>
+Date: Mon, 21 Sep 2015 19:19:53 +0300
+Subject: mwifiex: fix mwifiex_rdeeprom_read()
+
+From: Dan Carpenter <dan.carpenter@oracle.com>
+
+commit 1f9c6e1bc1ba5f8a10fcd6e99d170954d7c6d382 upstream.
+
+There were several bugs here.
+
+1) The done label was in the wrong place so we didn't copy any
+ information out when there was no command given.
+
+2) We were using PAGE_SIZE as the size of the buffer instead of
+ "PAGE_SIZE - pos".
+
+3) snprintf() returns the number of characters that would have been
+ printed if there were enough space. If there was not enough space
+ (and we had fixed the memory corruption bug #2) then it would result
+ in an information leak when we do simple_read_from_buffer(). I've
+ changed it to use scnprintf() instead.
+
+I also removed the initialization at the start of the function, because
+I thought it made the code a little more clear.
+
+Fixes: 5e6e3a92b9a4 ('wireless: mwifiex: initial commit for Marvell mwifiex driver')
+Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
+Acked-by: Amitkumar Karwar <akarwar@marvell.com>
+Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/net/wireless/mwifiex/debugfs.c | 14 +++++++-------
+ 1 file changed, 7 insertions(+), 7 deletions(-)
+
+--- a/drivers/net/wireless/mwifiex/debugfs.c
++++ b/drivers/net/wireless/mwifiex/debugfs.c
+@@ -637,7 +637,7 @@ mwifiex_rdeeprom_read(struct file *file,
+ (struct mwifiex_private *) file->private_data;
+ unsigned long addr = get_zeroed_page(GFP_KERNEL);
+ char *buf = (char *) addr;
+- int pos = 0, ret = 0, i;
++ int pos, ret, i;
+ u8 value[MAX_EEPROM_DATA];
+
+ if (!buf)
+@@ -645,7 +645,7 @@ mwifiex_rdeeprom_read(struct file *file,
+
+ if (saved_offset == -1) {
+ /* No command has been given */
+- pos += snprintf(buf, PAGE_SIZE, "0");
++ pos = snprintf(buf, PAGE_SIZE, "0");
+ goto done;
+ }
+
+@@ -654,17 +654,17 @@ mwifiex_rdeeprom_read(struct file *file,
+ (u16) saved_bytes, value);
+ if (ret) {
+ ret = -EINVAL;
+- goto done;
++ goto out_free;
+ }
+
+- pos += snprintf(buf, PAGE_SIZE, "%d %d ", saved_offset, saved_bytes);
++ pos = snprintf(buf, PAGE_SIZE, "%d %d ", saved_offset, saved_bytes);
+
+ for (i = 0; i < saved_bytes; i++)
+- pos += snprintf(buf + strlen(buf), PAGE_SIZE, "%d ", value[i]);
+-
+- ret = simple_read_from_buffer(ubuf, count, ppos, buf, pos);
++ pos += scnprintf(buf + pos, PAGE_SIZE - pos, "%d ", value[i]);
+
+ done:
++ ret = simple_read_from_buffer(ubuf, count, ppos, buf, pos);
++out_free:
+ free_page(addr);
+ return ret;
+ }
--- /dev/null
+From 2502d0ef272da7058ef303b849a2c8dc324c2e2e Mon Sep 17 00:00:00 2001
+From: Maxime Ripard <maxime.ripard@free-electrons.com>
+Date: Fri, 25 Sep 2015 18:09:35 +0200
+Subject: net: mvneta: Fix CPU_MAP registers initialisation
+
+From: Maxime Ripard <maxime.ripard@free-electrons.com>
+
+commit 2502d0ef272da7058ef303b849a2c8dc324c2e2e upstream.
+
+The CPU_MAP register is duplicated for each CPUs at different addresses,
+each instance being at a different address.
+
+However, the code so far was using CONFIG_NR_CPUS to initialise the CPU_MAP
+registers for each registers, while the SoCs embed at most 4 CPUs.
+
+This is especially an issue with multi_v7_defconfig, where CONFIG_NR_CPUS
+is currently set to 16, resulting in writes to registers that are not
+CPU_MAP.
+
+Fixes: c5aff18204da ("net: mvneta: driver for Marvell Armada 370/XP network unit")
+Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
+Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/net/ethernet/marvell/mvneta.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/net/ethernet/marvell/mvneta.c
++++ b/drivers/net/ethernet/marvell/mvneta.c
+@@ -910,7 +910,7 @@ static void mvneta_defaults_set(struct m
+ /* Set CPU queue access map - all CPUs have access to all RX
+ * queues and to all TX queues
+ */
+- for (cpu = 0; cpu < CONFIG_NR_CPUS; cpu++)
++ for_each_present_cpu(cpu)
+ mvreg_write(pp, MVNETA_CPU_MAP(cpu),
+ (MVNETA_CPU_RXQ_ACCESS_ALL_MASK |
+ MVNETA_CPU_TXQ_ACCESS_ALL_MASK));
arm-8426-1-dma-mapping-add-missing-range-check-in-dma_mmap.patch
arm-8427-1-dma-mapping-add-support-for-offset-parameter-in-dma_mmap.patch
arm-orion-fix-dsa-platform-device-after-mvmdio-conversion.patch
+x86-setup-extend-low-identity-map-to-cover-whole-kernel-range.patch
+x86-setup-fix-low-identity-map-for-2gb-kernel-range.patch
+x86-cpu-call-verify_cpu-after-having-entered-long-mode-too.patch
+x86-cpu-fix-smap-check-in-pvops-environments.patch
+mac80211-fix-driver-rssi-event-calculations.patch
+net-mvneta-fix-cpu_map-registers-initialisation.patch
+mwifiex-fix-mwifiex_rdeeprom_read.patch
+staging-rtl8712-add-device-id-for-sitecom-wla2100.patch
+bluetooth-hidp-fix-device-disconnect-on-idle-timeout.patch
+can-sja1000-clear-interrupts-on-start.patch
+arm64-fix-compat-register-mappings.patch
--- /dev/null
+From 1e6e63283691a2a9048a35d9c6c59cf0abd342e4 Mon Sep 17 00:00:00 2001
+From: Larry Finger <Larry.Finger@lwfinger.net>
+Date: Sun, 18 Oct 2015 22:14:48 -0500
+Subject: staging: rtl8712: Add device ID for Sitecom WLA2100
+
+From: Larry Finger <Larry.Finger@lwfinger.net>
+
+commit 1e6e63283691a2a9048a35d9c6c59cf0abd342e4 upstream.
+
+This adds the USB ID for the Sitecom WLA2100. The Windows 10 inf file
+was checked to verify that the addition is correct.
+
+Reported-by: Frans van de Wiel <fvdw@fvdw.eu>
+Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
+Cc: Frans van de Wiel <fvdw@fvdw.eu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/staging/rtl8712/usb_intf.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/staging/rtl8712/usb_intf.c
++++ b/drivers/staging/rtl8712/usb_intf.c
+@@ -144,6 +144,7 @@ static struct usb_device_id rtl871x_usb_
+ {USB_DEVICE(0x0DF6, 0x0058)},
+ {USB_DEVICE(0x0DF6, 0x0049)},
+ {USB_DEVICE(0x0DF6, 0x004C)},
++ {USB_DEVICE(0x0DF6, 0x006C)},
+ {USB_DEVICE(0x0DF6, 0x0064)},
+ /* Skyworth */
+ {USB_DEVICE(0x14b2, 0x3300)},
--- /dev/null
+From 04633df0c43d710e5f696b06539c100898678235 Mon Sep 17 00:00:00 2001
+From: Borislav Petkov <bp@suse.de>
+Date: Thu, 5 Nov 2015 16:57:56 +0100
+Subject: x86/cpu: Call verify_cpu() after having entered long mode too
+
+From: Borislav Petkov <bp@suse.de>
+
+commit 04633df0c43d710e5f696b06539c100898678235 upstream.
+
+When we get loaded by a 64-bit bootloader, kernel entry point is
+startup_64 in head_64.S. We don't trust any and all bootloaders because
+some will fiddle with CPU configuration so we go ahead and massage each
+CPU into sanity again.
+
+For example, some dell BIOSes have this XD disable feature which set
+IA32_MISC_ENABLE[34] and disable NX. This might be some dumb workaround
+for other OSes but Linux sure doesn't need it.
+
+A similar thing is present in the Surface 3 firmware - see
+https://bugzilla.kernel.org/show_bug.cgi?id=106051 - which sets this bit
+only on the BSP:
+
+ # rdmsr -a 0x1a0
+ 400850089
+ 850089
+ 850089
+ 850089
+
+I know, right?!
+
+There's not even an off switch in there.
+
+So fix all those cases by sanitizing the 64-bit entry point too. For
+that, make verify_cpu() callable in 64-bit mode also.
+
+Requested-and-debugged-by: "H. Peter Anvin" <hpa@zytor.com>
+Reported-and-tested-by: Bastien Nocera <bugzilla@hadess.net>
+Signed-off-by: Borislav Petkov <bp@suse.de>
+Cc: Matt Fleming <matt@codeblueprint.co.uk>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Link: http://lkml.kernel.org/r/1446739076-21303-1-git-send-email-bp@alien8.de
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/kernel/head_64.S | 8 ++++++++
+ arch/x86/kernel/verify_cpu.S | 12 +++++++-----
+ 2 files changed, 15 insertions(+), 5 deletions(-)
+
+--- a/arch/x86/kernel/head_64.S
++++ b/arch/x86/kernel/head_64.S
+@@ -65,6 +65,9 @@ startup_64:
+ * tables and then reload them.
+ */
+
++ /* Sanitize CPU configuration */
++ call verify_cpu
++
+ /*
+ * Compute the delta between the address I am compiled to run at and the
+ * address I am actually running at.
+@@ -174,6 +177,9 @@ ENTRY(secondary_startup_64)
+ * after the boot processor executes this code.
+ */
+
++ /* Sanitize CPU configuration */
++ call verify_cpu
++
+ movq $(init_level4_pgt - __START_KERNEL_map), %rax
+ 1:
+
+@@ -288,6 +294,8 @@ ENTRY(secondary_startup_64)
+ pushq %rax # target address in negative space
+ lretq
+
++#include "verify_cpu.S"
++
+ #ifdef CONFIG_HOTPLUG_CPU
+ /*
+ * Boot CPU0 entry point. It's called from play_dead(). Everything has been set
+--- a/arch/x86/kernel/verify_cpu.S
++++ b/arch/x86/kernel/verify_cpu.S
+@@ -34,10 +34,11 @@
+ #include <asm/msr-index.h>
+
+ verify_cpu:
+- pushfl # Save caller passed flags
+- pushl $0 # Kill any dangerous flags
+- popfl
++ pushf # Save caller passed flags
++ push $0 # Kill any dangerous flags
++ popf
+
++#ifndef __x86_64__
+ pushfl # standard way to check for cpuid
+ popl %eax
+ movl %eax,%ebx
+@@ -48,6 +49,7 @@ verify_cpu:
+ popl %eax
+ cmpl %eax,%ebx
+ jz verify_cpu_no_longmode # cpu has no cpuid
++#endif
+
+ movl $0x0,%eax # See if cpuid 1 is implemented
+ cpuid
+@@ -130,10 +132,10 @@ verify_cpu_sse_test:
+ jmp verify_cpu_sse_test # try again
+
+ verify_cpu_no_longmode:
+- popfl # Restore caller passed flags
++ popf # Restore caller passed flags
+ movl $1,%eax
+ ret
+ verify_cpu_sse_ok:
+- popfl # Restore caller passed flags
++ popf # Restore caller passed flags
+ xorl %eax, %eax
+ ret
--- /dev/null
+From 581b7f158fe0383b492acd1ce3fb4e99d4e57808 Mon Sep 17 00:00:00 2001
+From: Andrew Cooper <andrew.cooper3@citrix.com>
+Date: Wed, 3 Jun 2015 10:31:14 +0100
+Subject: x86/cpu: Fix SMAP check in PVOPS environments
+
+From: Andrew Cooper <andrew.cooper3@citrix.com>
+
+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 <andrew.cooper3@citrix.com>
+Reviewed-by: David Vrabel <david.vrabel@citrix.com>
+Tested-by: Rusty Russell <rusty@rustcorp.com.au>
+Cc: Rusty Russell <rusty@rustcorp.com.au>
+Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
+Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
+Cc: <lguest@lists.ozlabs.org>
+Cc: Xen-devel <xen-devel@lists.xen.org>
+Link: http://lkml.kernel.org/r/1433323874-6927-1-git-send-email-andrew.cooper3@citrix.com
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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)) {
--- /dev/null
+From f5f3497cad8c8416a74b9aaceb127908755d020a Mon Sep 17 00:00:00 2001
+From: Paolo Bonzini <pbonzini@redhat.com>
+Date: Wed, 14 Oct 2015 13:30:45 +0200
+Subject: x86/setup: Extend low identity map to cover whole kernel range
+
+From: Paolo Bonzini <pbonzini@redhat.com>
+
+commit f5f3497cad8c8416a74b9aaceb127908755d020a upstream.
+
+On 32-bit systems, the initial_page_table is reused by
+efi_call_phys_prolog as an identity map to call
+SetVirtualAddressMap. efi_call_phys_prolog takes care of
+converting the current CPU's GDT to a physical address too.
+
+For PAE kernels the identity mapping is achieved by aliasing the
+first PDPE for the kernel memory mapping into the first PDPE
+of initial_page_table. This makes the EFI stub's trick "just work".
+
+However, for non-PAE kernels there is no guarantee that the identity
+mapping in the initial_page_table extends as far as the GDT; in this
+case, accesses to the GDT will cause a page fault (which quickly becomes
+a triple fault). Fix this by copying the kernel mappings from
+swapper_pg_dir to initial_page_table twice, both at PAGE_OFFSET and at
+identity mapping.
+
+For some reason, this is only reproducible with QEMU's dynamic translation
+mode, and not for example with KVM. However, even under KVM one can clearly
+see that the page table is bogus:
+
+ $ qemu-system-i386 -pflash OVMF.fd -M q35 vmlinuz0 -s -S -daemonize
+ $ gdb
+ (gdb) target remote localhost:1234
+ (gdb) hb *0x02858f6f
+ Hardware assisted breakpoint 1 at 0x2858f6f
+ (gdb) c
+ Continuing.
+
+ Breakpoint 1, 0x02858f6f in ?? ()
+ (gdb) monitor info registers
+ ...
+ GDT= 0724e000 000000ff
+ IDT= fffbb000 000007ff
+ CR0=0005003b CR2=ff896000 CR3=032b7000 CR4=00000690
+ ...
+
+The page directory is sane:
+
+ (gdb) x/4wx 0x32b7000
+ 0x32b7000: 0x03398063 0x03399063 0x0339a063 0x0339b063
+ (gdb) x/4wx 0x3398000
+ 0x3398000: 0x00000163 0x00001163 0x00002163 0x00003163
+ (gdb) x/4wx 0x3399000
+ 0x3399000: 0x00400003 0x00401003 0x00402003 0x00403003
+
+but our particular page directory entry is empty:
+
+ (gdb) x/1wx 0x32b7000 + (0x724e000 >> 22) * 4
+ 0x32b7070: 0x00000000
+
+[ It appears that you can skate past this issue if you don't receive
+ any interrupts while the bogus GDT pointer is loaded, or if you avoid
+ reloading the segment registers in general.
+
+ Andy Lutomirski provides some additional insight:
+
+ "AFAICT it's entirely permissible for the GDTR and/or LDT
+ descriptor to point to unmapped memory. Any attempt to use them
+ (segment loads, interrupts, IRET, etc) will try to access that memory
+ as if the access came from CPL 0 and, if the access fails, will
+ generate a valid page fault with CR2 pointing into the GDT or
+ LDT."
+
+ Up until commit 23a0d4e8fa6d ("efi: Disable interrupts around EFI
+ calls, not in the epilog/prolog calls") interrupts were disabled
+ around the prolog and epilog calls, and the functional GDT was
+ re-installed before interrupts were re-enabled.
+
+ Which explains why no one has hit this issue until now. ]
+
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Reported-by: Laszlo Ersek <lersek@redhat.com>
+Cc: <stable@vger.kernel.org>
+Cc: Borislav Petkov <bp@alien8.de>
+Cc: "H. Peter Anvin" <hpa@zytor.com>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Cc: Ingo Molnar <mingo@kernel.org>
+Cc: Andy Lutomirski <luto@amacapital.net>
+Signed-off-by: Matt Fleming <matt.fleming@intel.com>
+[ Updated changelog. ]
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/kernel/setup.c | 8 ++++++++
+ 1 file changed, 8 insertions(+)
+
+--- a/arch/x86/kernel/setup.c
++++ b/arch/x86/kernel/setup.c
+@@ -1156,6 +1156,14 @@ void __init setup_arch(char **cmdline_p)
+ clone_pgd_range(initial_page_table + KERNEL_PGD_BOUNDARY,
+ swapper_pg_dir + KERNEL_PGD_BOUNDARY,
+ KERNEL_PGD_PTRS);
++
++ /*
++ * sync back low identity map too. It is used for example
++ * in the 32-bit EFI stub.
++ */
++ clone_pgd_range(initial_page_table,
++ swapper_pg_dir + KERNEL_PGD_BOUNDARY,
++ KERNEL_PGD_PTRS);
+ #endif
+
+ tboot_probe();
--- /dev/null
+From 68accac392d859d24adcf1be3a90e41f978bd54c Mon Sep 17 00:00:00 2001
+From: Krzysztof Mazur <krzysiek@podlesie.net>
+Date: Fri, 6 Nov 2015 14:18:36 +0100
+Subject: x86/setup: Fix low identity map for >= 2GB kernel range
+
+From: Krzysztof Mazur <krzysiek@podlesie.net>
+
+commit 68accac392d859d24adcf1be3a90e41f978bd54c upstream.
+
+The commit f5f3497cad8c extended the low identity mapping. However, if
+the kernel uses more than 2 GB (VMSPLIT_2G_OPT or VMSPLIT_1G memory
+split), the normal memory mapping is overwritten by the low identity
+mapping causing a crash. To avoid overwritting, limit the low identity
+map to cover only memory before kernel range (PAGE_OFFSET).
+
+Fixes: f5f3497cad8c "x86/setup: Extend low identity map to cover whole kernel range
+Signed-off-by: Krzysztof Mazur <krzysiek@podlesie.net>
+Cc: Andy Lutomirski <luto@amacapital.net>
+Cc: Borislav Petkov <bp@alien8.de>
+Cc: Laszlo Ersek <lersek@redhat.com>
+Cc: Matt Fleming <matt.fleming@intel.com>
+Cc: Paolo Bonzini <pbonzini@redhat.com>
+Link: http://lkml.kernel.org/r/1446815916-22105-1-git-send-email-krzysiek@podlesie.net
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/kernel/setup.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/x86/kernel/setup.c
++++ b/arch/x86/kernel/setup.c
+@@ -1163,7 +1163,7 @@ void __init setup_arch(char **cmdline_p)
+ */
+ clone_pgd_range(initial_page_table,
+ swapper_pg_dir + KERNEL_PGD_BOUNDARY,
+- KERNEL_PGD_PTRS);
++ min(KERNEL_PGD_PTRS, KERNEL_PGD_BOUNDARY));
+ #endif
+
+ tboot_probe();
projects / thirdparty / kernel / stable-queue.git / commitdiff
