--- /dev/null
+From 1de63d60cd5b0d33a812efa455d5933bf1564a51 Mon Sep 17 00:00:00 2001
+From: Satoru Takeuchi <takeuchi_satoru@jp.fujitsu.com>
+Date: Thu, 14 Feb 2013 09:12:52 +0900
+Subject: efi: Clear EFI_RUNTIME_SERVICES rather than EFI_BOOT by "noefi" boot parameter
+
+From: Satoru Takeuchi <takeuchi_satoru@jp.fujitsu.com>
+
+commit 1de63d60cd5b0d33a812efa455d5933bf1564a51 upstream.
+
+There was a serious problem in samsung-laptop that its platform driver is
+designed to run under BIOS and running under EFI can cause the machine to
+become bricked or can cause Machine Check Exceptions.
+
+ Discussion about this problem:
+ https://bugs.launchpad.net/ubuntu-cdimage/+bug/1040557
+ https://bugzilla.kernel.org/show_bug.cgi?id=47121
+
+ The patches to fix this problem:
+ efi: Make 'efi_enabled' a function to query EFI facilities
+ 83e68189745ad931c2afd45d8ee3303929233e7f
+
+ samsung-laptop: Disable on EFI hardware
+ e0094244e41c4d0c7ad69920681972fc45d8ce34
+
+Unfortunately this problem comes back again if users specify "noefi" option.
+This parameter clears EFI_BOOT and that driver continues to run even if running
+under EFI. Refer to the document, this parameter should clear
+EFI_RUNTIME_SERVICES instead.
+
+Documentation/kernel-parameters.txt:
+===============================================================================
+...
+ noefi [X86] Disable EFI runtime services support.
+...
+===============================================================================
+
+Documentation/x86/x86_64/uefi.txt:
+===============================================================================
+...
+- If some or all EFI runtime services don't work, you can try following
+ kernel command line parameters to turn off some or all EFI runtime
+ services.
+ noefi turn off all EFI runtime services
+...
+===============================================================================
+
+Signed-off-by: Satoru Takeuchi <takeuchi_satoru@jp.fujitsu.com>
+Link: http://lkml.kernel.org/r/511C2C04.2070108@jp.fujitsu.com
+Cc: Matt Fleming <matt.fleming@intel.com>
+Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/platform/efi/efi.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/x86/platform/efi/efi.c
++++ b/arch/x86/platform/efi/efi.c
+@@ -87,7 +87,7 @@ EXPORT_SYMBOL(efi_enabled);
+
+ static int __init setup_noefi(char *arg)
+ {
+- clear_bit(EFI_BOOT, &x86_efi_facility);
++ clear_bit(EFI_RUNTIME_SERVICES, &x86_efi_facility);
+ return 0;
+ }
+ early_param("noefi", setup_noefi);
--- /dev/null
+From 249bfb83cf8ba658955f0245ac3981d941f746ee Mon Sep 17 00:00:00 2001
+From: "Rafael J. Wysocki" <rjw@sisk.pl>
+Date: Mon, 11 Feb 2013 20:49:49 +0100
+Subject: PCI/PM: Clean up PME state when removing a device
+
+From: "Rafael J. Wysocki" <rjw@sisk.pl>
+
+commit 249bfb83cf8ba658955f0245ac3981d941f746ee upstream.
+
+Devices are added to pci_pme_list when drivers use pci_enable_wake()
+or pci_wake_from_d3(), but they aren't removed from the list unless
+the driver explicitly disables wakeup. Many drivers never disable
+wakeup, so their devices remain on the list even after they are
+removed, e.g., via hotplug. A subsequent PME poll will oops when
+it tries to touch the device.
+
+This patch disables PME# on a device before removing it, which removes
+the device from pci_pme_list. This is safe even if the device never
+had PME# enabled.
+
+This oops can be triggered by unplugging a Thunderbolt ethernet adapter
+on a Macbook Pro, as reported by Daniel below.
+
+[bhelgaas: changelog]
+Reference: http://lkml.kernel.org/r/CAMVG2svG21yiM1wkH4_2pen2n+cr2-Zv7TbH3Gj+8MwevZjDbw@mail.gmail.com
+Reported-and-tested-by: Daniel J Blueman <daniel@quora.org>
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/pci/remove.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/pci/remove.c
++++ b/drivers/pci/remove.c
+@@ -19,6 +19,8 @@ static void pci_free_resources(struct pc
+
+ static void pci_stop_dev(struct pci_dev *dev)
+ {
++ pci_pme_active(dev, false);
++
+ if (dev->is_added) {
+ pci_proc_detach_device(dev);
+ pci_remove_sysfs_dev_files(dev);
--- /dev/null
+From 13d2b4d11d69a92574a55bfd985cfb0ca77aebdc Mon Sep 17 00:00:00 2001
+From: Jan Beulich <JBeulich@suse.com>
+Date: Thu, 24 Jan 2013 13:11:10 +0000
+Subject: x86/xen: don't assume %ds is usable in xen_iret for 32-bit PVOPS.
+
+From: Jan Beulich <JBeulich@suse.com>
+
+commit 13d2b4d11d69a92574a55bfd985cfb0ca77aebdc upstream.
+
+This fixes CVE-2013-0228 / XSA-42
+
+Drew Jones while working on CVE-2013-0190 found that that unprivileged guest user
+in 32bit PV guest can use to crash the > guest with the panic like this:
+
+-------------
+general protection fault: 0000 [#1] SMP
+last sysfs file: /sys/devices/vbd-51712/block/xvda/dev
+Modules linked in: sunrpc ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4
+iptable_filter ip_tables ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6
+xt_state nf_conntrack ip6table_filter ip6_tables ipv6 xen_netfront ext4
+mbcache jbd2 xen_blkfront dm_mirror dm_region_hash dm_log dm_mod [last
+unloaded: scsi_wait_scan]
+
+Pid: 1250, comm: r Not tainted 2.6.32-356.el6.i686 #1
+EIP: 0061:[<c0407462>] EFLAGS: 00010086 CPU: 0
+EIP is at xen_iret+0x12/0x2b
+EAX: eb8d0000 EBX: 00000001 ECX: 08049860 EDX: 00000010
+ESI: 00000000 EDI: 003d0f00 EBP: b77f8388 ESP: eb8d1fe0
+ DS: 0000 ES: 007b FS: 0000 GS: 00e0 SS: 0069
+Process r (pid: 1250, ti=eb8d0000 task=c2953550 task.ti=eb8d0000)
+Stack:
+ 00000000 0027f416 00000073 00000206 b77f8364 0000007b 00000000 00000000
+Call Trace:
+Code: c3 8b 44 24 18 81 4c 24 38 00 02 00 00 8d 64 24 30 e9 03 00 00 00
+8d 76 00 f7 44 24 08 00 00 02 80 75 33 50 b8 00 e0 ff ff 21 e0 <8b> 40
+10 8b 04 85 a0 f6 ab c0 8b 80 0c b0 b3 c0 f6 44 24 0d 02
+EIP: [<c0407462>] xen_iret+0x12/0x2b SS:ESP 0069:eb8d1fe0
+general protection fault: 0000 [#2]
+---[ end trace ab0d29a492dcd330 ]---
+Kernel panic - not syncing: Fatal exception
+Pid: 1250, comm: r Tainted: G D ---------------
+2.6.32-356.el6.i686 #1
+Call Trace:
+ [<c08476df>] ? panic+0x6e/0x122
+ [<c084b63c>] ? oops_end+0xbc/0xd0
+ [<c084b260>] ? do_general_protection+0x0/0x210
+ [<c084a9b7>] ? error_code+0x73/
+-------------
+
+Petr says: "
+ I've analysed the bug and I think that xen_iret() cannot cope with
+ mangled DS, in this case zeroed out (null selector/descriptor) by either
+ xen_failsafe_callback() or RESTORE_REGS because the corresponding LDT
+ entry was invalidated by the reproducer. "
+
+Jan took a look at the preliminary patch and came up a fix that solves
+this problem:
+
+"This code gets called after all registers other than those handled by
+IRET got already restored, hence a null selector in %ds or a non-null
+one that got loaded from a code or read-only data descriptor would
+cause a kernel mode fault (with the potential of crashing the kernel
+as a whole, if panic_on_oops is set)."
+
+The way to fix this is to realize that the we can only relay on the
+registers that IRET restores. The two that are guaranteed are the
+%cs and %ss as they are always fixed GDT selectors. Also they are
+inaccessible from user mode - so they cannot be altered. This is
+the approach taken in this patch.
+
+Another alternative option suggested by Jan would be to relay on
+the subtle realization that using the %ebp or %esp relative references uses
+the %ss segment. In which case we could switch from using %eax to %ebp and
+would not need the %ss over-rides. That would also require one extra
+instruction to compensate for the one place where the register is used
+as scaled index. However Andrew pointed out that is too subtle and if
+further work was to be done in this code-path it could escape folks attention
+and lead to accidents.
+
+Reviewed-by: Petr Matousek <pmatouse@redhat.com>
+Reported-by: Petr Matousek <pmatouse@redhat.com>
+Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
+Signed-off-by: Jan Beulich <jbeulich@suse.com>
+Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/xen/xen-asm_32.S | 14 +++++++-------
+ 1 file changed, 7 insertions(+), 7 deletions(-)
+
+--- a/arch/x86/xen/xen-asm_32.S
++++ b/arch/x86/xen/xen-asm_32.S
+@@ -89,11 +89,11 @@ ENTRY(xen_iret)
+ */
+ #ifdef CONFIG_SMP
+ GET_THREAD_INFO(%eax)
+- movl TI_cpu(%eax), %eax
+- movl __per_cpu_offset(,%eax,4), %eax
+- mov xen_vcpu(%eax), %eax
++ movl %ss:TI_cpu(%eax), %eax
++ movl %ss:__per_cpu_offset(,%eax,4), %eax
++ mov %ss:xen_vcpu(%eax), %eax
+ #else
+- movl xen_vcpu, %eax
++ movl %ss:xen_vcpu, %eax
+ #endif
+
+ /* check IF state we're restoring */
+@@ -106,11 +106,11 @@ ENTRY(xen_iret)
+ * resuming the code, so we don't have to be worried about
+ * being preempted to another CPU.
+ */
+- setz XEN_vcpu_info_mask(%eax)
++ setz %ss:XEN_vcpu_info_mask(%eax)
+ xen_iret_start_crit:
+
+ /* check for unmasked and pending */
+- cmpw $0x0001, XEN_vcpu_info_pending(%eax)
++ cmpw $0x0001, %ss:XEN_vcpu_info_pending(%eax)
+
+ /*
+ * If there's something pending, mask events again so we can
+@@ -118,7 +118,7 @@ xen_iret_start_crit:
+ * touch XEN_vcpu_info_mask.
+ */
+ jne 1f
+- movb $1, XEN_vcpu_info_mask(%eax)
++ movb $1, %ss:XEN_vcpu_info_mask(%eax)
+
+ 1: popl %eax
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
