1. 10 12月, 2016 1 次提交
  2. 06 12月, 2016 2 次提交
  3. 28 11月, 2016 3 次提交
  4. 25 11月, 2016 4 次提交
    • R
      KVM: x86: check for pic and ioapic presence before use · df492896
      Radim Krčmář 提交于
      Split irqchip allows pic and ioapic routes to be used without them being
      created, which results in NULL access.  Check for NULL and avoid it.
      (The setup is too racy for a nicer solutions.)
      
      Found by syzkaller:
      
        general protection fault: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN
        Dumping ftrace buffer:
           (ftrace buffer empty)
        Modules linked in:
        CPU: 3 PID: 11923 Comm: kworker/3:2 Not tainted 4.9.0-rc5+ #27
        Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
        Workqueue: events irqfd_inject
        task: ffff88006a06c7c0 task.stack: ffff880068638000
        RIP: 0010:[...]  [...] __lock_acquire+0xb35/0x3380 kernel/locking/lockdep.c:3221
        RSP: 0000:ffff88006863ea20  EFLAGS: 00010006
        RAX: dffffc0000000000 RBX: dffffc0000000000 RCX: 0000000000000000
        RDX: 0000000000000039 RSI: 0000000000000000 RDI: 1ffff1000d0c7d9e
        RBP: ffff88006863ef58 R08: 0000000000000001 R09: 0000000000000000
        R10: 00000000000001c8 R11: 0000000000000000 R12: ffff88006a06c7c0
        R13: 0000000000000001 R14: ffffffff8baab1a0 R15: 0000000000000001
        FS:  0000000000000000(0000) GS:ffff88006d100000(0000) knlGS:0000000000000000
        CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
        CR2: 00000000004abdd0 CR3: 000000003e2f2000 CR4: 00000000000026e0
        Stack:
         ffffffff894d0098 1ffff1000d0c7d56 ffff88006863ecd0 dffffc0000000000
         ffff88006a06c7c0 0000000000000000 ffff88006863ecf8 0000000000000082
         0000000000000000 ffffffff815dd7c1 ffffffff00000000 ffffffff00000000
        Call Trace:
         [...] lock_acquire+0x2a2/0x790 kernel/locking/lockdep.c:3746
         [...] __raw_spin_lock include/linux/spinlock_api_smp.h:144
         [...] _raw_spin_lock+0x38/0x50 kernel/locking/spinlock.c:151
         [...] spin_lock include/linux/spinlock.h:302
         [...] kvm_ioapic_set_irq+0x4c/0x100 arch/x86/kvm/ioapic.c:379
         [...] kvm_set_ioapic_irq+0x8f/0xc0 arch/x86/kvm/irq_comm.c:52
         [...] kvm_set_irq+0x239/0x640 arch/x86/kvm/../../../virt/kvm/irqchip.c:101
         [...] irqfd_inject+0xb4/0x150 arch/x86/kvm/../../../virt/kvm/eventfd.c:60
         [...] process_one_work+0xb40/0x1ba0 kernel/workqueue.c:2096
         [...] worker_thread+0x214/0x18a0 kernel/workqueue.c:2230
         [...] kthread+0x328/0x3e0 kernel/kthread.c:209
         [...] ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:433
      Reported-by: NDmitry Vyukov <dvyukov@google.com>
      Cc: stable@vger.kernel.org
      Fixes: 49df6397 ("KVM: x86: Split the APIC from the rest of IRQCHIP.")
      Signed-off-by: NRadim Krčmář <rkrcmar@redhat.com>
      df492896
    • R
      KVM: x86: fix out-of-bounds accesses of rtc_eoi map · 81cdb259
      Radim Krčmář 提交于
      KVM was using arrays of size KVM_MAX_VCPUS with vcpu_id, but ID can be
      bigger that the maximal number of VCPUs, resulting in out-of-bounds
      access.
      
      Found by syzkaller:
      
        BUG: KASAN: slab-out-of-bounds in __apic_accept_irq+0xb33/0xb50 at addr [...]
        Write of size 1 by task a.out/27101
        CPU: 1 PID: 27101 Comm: a.out Not tainted 4.9.0-rc5+ #49
        Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
         [...]
        Call Trace:
         [...] __apic_accept_irq+0xb33/0xb50 arch/x86/kvm/lapic.c:905
         [...] kvm_apic_set_irq+0x10e/0x180 arch/x86/kvm/lapic.c:495
         [...] kvm_irq_delivery_to_apic+0x732/0xc10 arch/x86/kvm/irq_comm.c:86
         [...] ioapic_service+0x41d/0x760 arch/x86/kvm/ioapic.c:360
         [...] ioapic_set_irq+0x275/0x6c0 arch/x86/kvm/ioapic.c:222
         [...] kvm_ioapic_inject_all arch/x86/kvm/ioapic.c:235
         [...] kvm_set_ioapic+0x223/0x310 arch/x86/kvm/ioapic.c:670
         [...] kvm_vm_ioctl_set_irqchip arch/x86/kvm/x86.c:3668
         [...] kvm_arch_vm_ioctl+0x1a08/0x23c0 arch/x86/kvm/x86.c:3999
         [...] kvm_vm_ioctl+0x1fa/0x1a70 arch/x86/kvm/../../../virt/kvm/kvm_main.c:3099
      Reported-by: NDmitry Vyukov <dvyukov@google.com>
      Cc: stable@vger.kernel.org
      Fixes: af1bae54 ("KVM: x86: bump KVM_MAX_VCPU_ID to 1023")
      Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com>
      Reviewed-by: NDavid Hildenbrand <david@redhat.com>
      Signed-off-by: NRadim Krčmář <rkrcmar@redhat.com>
      81cdb259
    • R
      KVM: x86: drop error recovery in em_jmp_far and em_ret_far · 2117d539
      Radim Krčmář 提交于
      em_jmp_far and em_ret_far assumed that setting IP can only fail in 64
      bit mode, but syzkaller proved otherwise (and SDM agrees).
      Code segment was restored upon failure, but it was left uninitialized
      outside of long mode, which could lead to a leak of host kernel stack.
      We could have fixed that by always saving and restoring the CS, but we
      take a simpler approach and just break any guest that manages to fail
      as the error recovery is error-prone and modern CPUs don't need emulator
      for this.
      
      Found by syzkaller:
      
        WARNING: CPU: 2 PID: 3668 at arch/x86/kvm/emulate.c:2217 em_ret_far+0x428/0x480
        Kernel panic - not syncing: panic_on_warn set ...
      
        CPU: 2 PID: 3668 Comm: syz-executor Not tainted 4.9.0-rc4+ #49
        Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
         [...]
        Call Trace:
         [...] __dump_stack lib/dump_stack.c:15
         [...] dump_stack+0xb3/0x118 lib/dump_stack.c:51
         [...] panic+0x1b7/0x3a3 kernel/panic.c:179
         [...] __warn+0x1c4/0x1e0 kernel/panic.c:542
         [...] warn_slowpath_null+0x2c/0x40 kernel/panic.c:585
         [...] em_ret_far+0x428/0x480 arch/x86/kvm/emulate.c:2217
         [...] em_ret_far_imm+0x17/0x70 arch/x86/kvm/emulate.c:2227
         [...] x86_emulate_insn+0x87a/0x3730 arch/x86/kvm/emulate.c:5294
         [...] x86_emulate_instruction+0x520/0x1ba0 arch/x86/kvm/x86.c:5545
         [...] emulate_instruction arch/x86/include/asm/kvm_host.h:1116
         [...] complete_emulated_io arch/x86/kvm/x86.c:6870
         [...] complete_emulated_mmio+0x4e9/0x710 arch/x86/kvm/x86.c:6934
         [...] kvm_arch_vcpu_ioctl_run+0x3b7a/0x5a90 arch/x86/kvm/x86.c:6978
         [...] kvm_vcpu_ioctl+0x61e/0xdd0 arch/x86/kvm/../../../virt/kvm/kvm_main.c:2557
         [...] vfs_ioctl fs/ioctl.c:43
         [...] do_vfs_ioctl+0x18c/0x1040 fs/ioctl.c:679
         [...] SYSC_ioctl fs/ioctl.c:694
         [...] SyS_ioctl+0x8f/0xc0 fs/ioctl.c:685
         [...] entry_SYSCALL_64_fastpath+0x1f/0xc2
      Reported-by: NDmitry Vyukov <dvyukov@google.com>
      Cc: stable@vger.kernel.org
      Fixes: d1442d85 ("KVM: x86: Handle errors when RIP is set during far jumps")
      Signed-off-by: NRadim Krčmář <rkrcmar@redhat.com>
      2117d539
    • R
      KVM: x86: fix out-of-bounds access in lapic · 444fdad8
      Radim Krčmář 提交于
      Cluster xAPIC delivery incorrectly assumed that dest_id <= 0xff.
      With enabled KVM_X2APIC_API_USE_32BIT_IDS in KVM_CAP_X2APIC_API, a
      userspace can send an interrupt with dest_id that results in
      out-of-bounds access.
      
      Found by syzkaller:
      
        BUG: KASAN: slab-out-of-bounds in kvm_irq_delivery_to_apic_fast+0x11fa/0x1210 at addr ffff88003d9ca750
        Read of size 8 by task syz-executor/22923
        CPU: 0 PID: 22923 Comm: syz-executor Not tainted 4.9.0-rc4+ #49
        Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
         [...]
        Call Trace:
         [...] __dump_stack lib/dump_stack.c:15
         [...] dump_stack+0xb3/0x118 lib/dump_stack.c:51
         [...] kasan_object_err+0x1c/0x70 mm/kasan/report.c:156
         [...] print_address_description mm/kasan/report.c:194
         [...] kasan_report_error mm/kasan/report.c:283
         [...] kasan_report+0x231/0x500 mm/kasan/report.c:303
         [...] __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:329
         [...] kvm_irq_delivery_to_apic_fast+0x11fa/0x1210 arch/x86/kvm/lapic.c:824
         [...] kvm_irq_delivery_to_apic+0x132/0x9a0 arch/x86/kvm/irq_comm.c:72
         [...] kvm_set_msi+0x111/0x160 arch/x86/kvm/irq_comm.c:157
         [...] kvm_send_userspace_msi+0x201/0x280 arch/x86/kvm/../../../virt/kvm/irqchip.c:74
         [...] kvm_vm_ioctl+0xba5/0x1670 arch/x86/kvm/../../../virt/kvm/kvm_main.c:3015
         [...] vfs_ioctl fs/ioctl.c:43
         [...] do_vfs_ioctl+0x18c/0x1040 fs/ioctl.c:679
         [...] SYSC_ioctl fs/ioctl.c:694
         [...] SyS_ioctl+0x8f/0xc0 fs/ioctl.c:685
         [...] entry_SYSCALL_64_fastpath+0x1f/0xc2
      Reported-by: NDmitry Vyukov <dvyukov@google.com>
      Cc: stable@vger.kernel.org
      Fixes: e45115b6 ("KVM: x86: use physical LAPIC array for logical x2APIC")
      Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: NRadim Krčmář <rkrcmar@redhat.com>
      444fdad8
  5. 24 11月, 2016 2 次提交
    • D
      x86/apic/uv: Silence a shift wrapping warning · c4597fd7
      Dan Carpenter 提交于
      'm_io' is stored in 6 bits so it's a number in the 0-63 range.  Static
      analysis tools complain that 1 << 63 will wrap so I have changed it to
      1ULL << m_io.
      
      This code is over three years old so presumably the bug doesn't happen
      very frequently in real life or someone would have complained by now.
      Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
      Cc: Alex Thorlton <athorlton@sgi.com>
      Cc: Dimitri Sivanich <sivanich@sgi.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Mike Travis <travis@sgi.com>
      Cc: Nathan Zimmer <nzimmer@sgi.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: kernel-janitors@vger.kernel.org
      Fixes: b15cc4a1 ("x86, uv, uv3: Update x2apic Support for SGI UV3")
      Link: http://lkml.kernel.org/r/20161123221908.GA23997@mwandaSigned-off-by: NIngo Molnar <mingo@kernel.org>
      c4597fd7
    • D
      x86/coredump: Always use user_regs_struct for compat_elf_gregset_t · 7b2dd368
      Dmitry Safonov 提交于
      Commit:
      
        90954e7b ("x86/coredump: Use pr_reg size, rather that TIF_IA32 flag")
      
      changed the coredumping code to construct the elf coredump file according
      to register set size - and that's good: if binary crashes with 32-bit code
      selector, generate 32-bit ELF core, otherwise - 64-bit core.
      
      That was made for restoring 32-bit applications on x86_64: we want
      32-bit application after restore to generate 32-bit ELF dump on crash.
      
      All was quite good and recently I started reworking 32-bit applications
      dumping part of CRIU: now it has two parasites (32 and 64) for seizing
      compat/native tasks, after rework it'll have one parasite, working in
      64-bit mode, to which 32-bit prologue long-jumps during infection.
      
      And while it has worked for my work machine, in VM with
      !CONFIG_X86_X32_ABI during reworking I faced that segfault in 32-bit
      binary, that has long-jumped to 64-bit mode results in dereference
      of garbage:
      
       32-victim[19266]: segfault at f775ef65 ip 00000000f775ef65 sp 00000000f776aa50 error 14
       BUG: unable to handle kernel paging request at ffffffffffffffff
       IP: [<ffffffff81332ce0>] strlen+0x0/0x20
       [...]
       Call Trace:
        [] elf_core_dump+0x11a9/0x1480
        [] do_coredump+0xa6b/0xe60
        [] get_signal+0x1a8/0x5c0
        [] do_signal+0x23/0x660
        [] exit_to_usermode_loop+0x34/0x65
        [] prepare_exit_to_usermode+0x2f/0x40
        [] retint_user+0x8/0x10
      
      That's because we have 64-bit registers set (with according total size)
      and we're writing it to elf_thread_core_info which has smaller size
      on !CONFIG_X86_X32_ABI. That lead to overwriting ELF notes part.
      
      Tested on 32-, 64-bit ELF crashes and on 32-bit binaries that have
      jumped with 64-bit code selector - all is readable with gdb.
      Signed-off-by: NDmitry Safonov <dsafonov@virtuozzo.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-mm@kvack.org
      Fixes: 90954e7b ("x86/coredump: Use pr_reg size, rather that TIF_IA32 flag")
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      7b2dd368
  6. 22 11月, 2016 3 次提交
    • P
      perf/x86/intel/uncore: Allow only a single PMU/box within an events group · 033ac60c
      Peter Zijlstra 提交于
      Group validation expects all events to be of the same PMU; however
      is_uncore_pmu() is too wide, it matches _all_ uncore events, even
      across PMUs.
      
      This triggers failure when we group different events from different
      uncore PMUs, like:
      
        perf stat -vv -e '{uncore_cbox_0/config=0x0334/,uncore_qpi_0/event=1/}' -a sleep 1
      
      Fix is_uncore_pmu() by only matching events to the box at hand.
      
      Note that generic code; ran after this step; will disallow this
      mixture of PMU events.
      Reported-by: NJiri Olsa <jolsa@redhat.com>
      Tested-by: NJiri Olsa <jolsa@redhat.com>
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Kan Liang <kan.liang@intel.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Vince Weaver <vince@deater.net>
      Cc: Vince Weaver <vincent.weaver@maine.edu>
      Link: http://lkml.kernel.org/r/20161118125354.GQ3117@twins.programming.kicks-ass.netSigned-off-by: NIngo Molnar <mingo@kernel.org>
      033ac60c
    • P
      perf/x86/intel: Cure bogus unwind from PEBS entries · b8000586
      Peter Zijlstra 提交于
      Vince Weaver reported that perf_fuzzer + KASAN detects that PEBS event
      unwinds sometimes do 'weird' things. In particular, we seemed to be
      ending up unwinding from random places on the NMI stack.
      
      While it was somewhat expected that the event record BP,SP would not
      match the interrupt BP,SP in that the interrupt is strictly later than
      the record event, it was overlooked that it could be on an already
      overwritten stack.
      
      Therefore, don't copy the recorded BP,SP over the interrupted BP,SP
      when we need stack unwinds.
      
      Note that its still possible the unwind doesn't full match the actual
      event, as its entirely possible to have done an (I)RET between record
      and interrupt, but on average it should still point in the general
      direction of where the event came from. Also, it's the best we can do,
      considering.
      
      The particular scenario that triggered the bogus NMI stack unwind was
      a PEBS event with very short period, upon enabling the event at the
      tail of the PMI handler (FREEZE_ON_PMI is not used), it instantly
      triggers a record (while still on the NMI stack) which in turn
      triggers the next PMI. This then causes back-to-back NMIs and we'll
      try and unwind the stack-frame from the last NMI, which obviously is
      now overwritten by our own.
      Analyzed-by: NJosh Poimboeuf <jpoimboe@redhat.com>
      Reported-by: NVince Weaver <vincent.weaver@maine.edu>
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@gmail.com>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: davej@codemonkey.org.uk <davej@codemonkey.org.uk>
      Cc: dvyukov@google.com <dvyukov@google.com>
      Cc: stable@vger.kernel.org
      Fixes: ca037701 ("perf, x86: Add PEBS infrastructure")
      Link: http://lkml.kernel.org/r/20161117171731.GV3157@twins.programming.kicks-ass.netSigned-off-by: NIngo Molnar <mingo@kernel.org>
      b8000586
    • J
      perf/x86: Restore TASK_SIZE check on frame pointer · ae31fe51
      Johannes Weiner 提交于
      The following commit:
      
        75925e1a ("perf/x86: Optimize stack walk user accesses")
      
      ... switched from copy_from_user_nmi() to __copy_from_user_nmi() with a manual
      access_ok() check.
      
      Unfortunately, copy_from_user_nmi() does an explicit check against TASK_SIZE,
      whereas the access_ok() uses whatever the current address limit of the task is.
      
      We are getting NMIs when __probe_kernel_read() has switched to KERNEL_DS, and
      then see vmalloc faults when we access what looks like pointers into vmalloc
      space:
      
        [] WARNING: CPU: 3 PID: 3685731 at arch/x86/mm/fault.c:435 vmalloc_fault+0x289/0x290
        [] CPU: 3 PID: 3685731 Comm: sh Tainted: G        W       4.6.0-5_fbk1_223_gdbf0f40 #1
        [] Call Trace:
        []  <NMI>  [<ffffffff814717d1>] dump_stack+0x4d/0x6c
        []  [<ffffffff81076e43>] __warn+0xd3/0xf0
        []  [<ffffffff81076f2d>] warn_slowpath_null+0x1d/0x20
        []  [<ffffffff8104a899>] vmalloc_fault+0x289/0x290
        []  [<ffffffff8104b5a0>] __do_page_fault+0x330/0x490
        []  [<ffffffff8104b70c>] do_page_fault+0xc/0x10
        []  [<ffffffff81794e82>] page_fault+0x22/0x30
        []  [<ffffffff81006280>] ? perf_callchain_user+0x100/0x2a0
        []  [<ffffffff8115124f>] get_perf_callchain+0x17f/0x190
        []  [<ffffffff811512c7>] perf_callchain+0x67/0x80
        []  [<ffffffff8114e750>] perf_prepare_sample+0x2a0/0x370
        []  [<ffffffff8114e840>] perf_event_output+0x20/0x60
        []  [<ffffffff8114aee7>] ? perf_event_update_userpage+0xc7/0x130
        []  [<ffffffff8114ea01>] __perf_event_overflow+0x181/0x1d0
        []  [<ffffffff8114f484>] perf_event_overflow+0x14/0x20
        []  [<ffffffff8100a6e3>] intel_pmu_handle_irq+0x1d3/0x490
        []  [<ffffffff8147daf7>] ? copy_user_enhanced_fast_string+0x7/0x10
        []  [<ffffffff81197191>] ? vunmap_page_range+0x1a1/0x2f0
        []  [<ffffffff811972f1>] ? unmap_kernel_range_noflush+0x11/0x20
        []  [<ffffffff814f2056>] ? ghes_copy_tofrom_phys+0x116/0x1f0
        []  [<ffffffff81040d1d>] ? x2apic_send_IPI_self+0x1d/0x20
        []  [<ffffffff8100411d>] perf_event_nmi_handler+0x2d/0x50
        []  [<ffffffff8101ea31>] nmi_handle+0x61/0x110
        []  [<ffffffff8101ef94>] default_do_nmi+0x44/0x110
        []  [<ffffffff8101f13b>] do_nmi+0xdb/0x150
        []  [<ffffffff81795187>] end_repeat_nmi+0x1a/0x1e
        []  [<ffffffff8147daf7>] ? copy_user_enhanced_fast_string+0x7/0x10
        []  [<ffffffff8147daf7>] ? copy_user_enhanced_fast_string+0x7/0x10
        []  [<ffffffff8147daf7>] ? copy_user_enhanced_fast_string+0x7/0x10
        []  <<EOE>>  <IRQ>  [<ffffffff8115d05e>] ? __probe_kernel_read+0x3e/0xa0
      
      Fix this by moving the valid_user_frame() check to before the uaccess
      that loads the return address and the pointer to the next frame.
      Signed-off-by: NJohannes Weiner <hannes@cmpxchg.org>
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Vince Weaver <vincent.weaver@maine.edu>
      Cc: linux-kernel@vger.kernel.org
      Fixes: 75925e1a ("perf/x86: Optimize stack walk user accesses")
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      ae31fe51
  7. 21 11月, 2016 6 次提交
  8. 20 11月, 2016 5 次提交
  9. 18 11月, 2016 3 次提交
  10. 17 11月, 2016 1 次提交
    • A
      x86/boot: Avoid warning for zero-filling .bss · 553bbc11
      Arnd Bergmann 提交于
      The latest binutils are warning about a .fill directive with an explicit
      value in a .bss section:
      
        arch/x86/kernel/head_32.S: Assembler messages:
        arch/x86/kernel/head_32.S:677: Warning: ignoring fill value in section `.bss..page_aligned'
        arch/x86/kernel/head_32.S:679: Warning: ignoring fill value in section `.bss..page_aligned'
      
      This comes from the 'ENTRY()' macro padding the space between the symbols
      with 'nop' via:
      
        .align 4,0x90
      
      Open-coding the .globl directive without the padding avoids that warning,
      as all the symbols are already page aligned.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/20161116141726.2013389-1-arnd@arndb.deSigned-off-by: NIngo Molnar <mingo@kernel.org>
      553bbc11
  11. 16 11月, 2016 3 次提交
  12. 13 11月, 2016 2 次提交
    • M
      x86/efi: Prevent mixed mode boot corruption with CONFIG_VMAP_STACK=y · f6697df3
      Matt Fleming 提交于
      Booting an EFI mixed mode kernel has been crashing since commit:
      
        e37e43a4 ("x86/mm/64: Enable vmapped stacks (CONFIG_HAVE_ARCH_VMAP_STACK=y)")
      
      The user-visible effect in my test setup was the kernel being unable
      to find the root file system ramdisk. This was likely caused by silent
      memory or page table corruption.
      
      Enabling CONFIG_DEBUG_VIRTUAL=y immediately flagged the thunking code as
      abusing virt_to_phys() because it was passing addresses that were not
      part of the kernel direct mapping.
      
      Use the slow version instead, which correctly handles all memory
      regions by performing a page table walk.
      Suggested-by: NAndy Lutomirski <luto@amacapital.net>
      Signed-off-by: NMatt Fleming <matt@codeblueprint.co.uk>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-efi@vger.kernel.org
      Link: http://lkml.kernel.org/r/20161112210424.5157-3-matt@codeblueprint.co.ukSigned-off-by: NIngo Molnar <mingo@kernel.org>
      f6697df3
    • B
      x86/efi: Fix EFI memmap pointer size warning · 02e56902
      Borislav Petkov 提交于
      Fix this when building on 32-bit:
      
        arch/x86/platform/efi/efi.c: In function ‘__efi_enter_virtual_mode’:
        arch/x86/platform/efi/efi.c:911:5: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
             (efi_memory_desc_t *)pa);
             ^
        arch/x86/platform/efi/efi.c:918:5: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
             (efi_memory_desc_t *)pa);
             ^
      
      The @pa local variable is declared as phys_addr_t and that is a u64 when
      CONFIG_PHYS_ADDR_T_64BIT=y. (The last is enabled on 32-bit on a PAE
      build.)
      
      However, its value comes from __pa() which is basically doing pointer
      arithmetic and checking, and returns unsigned long as it is the native
      pointer width.
      
      So let's use an unsigned long too. It should be fine to do so because
      the later users cast it to a pointer too.
      Signed-off-by: NBorislav Petkov <bp@suse.de>
      Signed-off-by: NMatt Fleming <matt@codeblueprint.co.uk>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-efi@vger.kernel.org
      Link: http://lkml.kernel.org/r/20161112210424.5157-2-matt@codeblueprint.co.ukSigned-off-by: NIngo Molnar <mingo@kernel.org>
      02e56902
  13. 12 11月, 2016 2 次提交
    • A
      crypto: aesni: shut up -Wmaybe-uninitialized warning · beae2c9e
      Arnd Bergmann 提交于
      The rfc4106 encrypy/decrypt helper functions cause an annoying
      false-positive warning in allmodconfig if we turn on
      -Wmaybe-uninitialized warnings again:
      
        arch/x86/crypto/aesni-intel_glue.c: In function ‘helper_rfc4106_decrypt’:
        include/linux/scatterlist.h:67:31: warning: ‘dst_sg_walk.sg’ may be used uninitialized in this function [-Wmaybe-uninitialized]
      
      The problem seems to be that the compiler doesn't track the state of the
      'one_entry_in_sg' variable across the kernel_fpu_begin/kernel_fpu_end
      section.
      
      This takes the easy way out by adding a bogus initialization, which
      should be harmless enough to get the patch into v4.9 so we can turn on
      this warning again by default without producing useless output.  A
      follow-up patch for v4.10 rearranges the code to make the warning go
      away.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      beae2c9e
    • A
      x86: apm: avoid uninitialized data · 3a6d8676
      Arnd Bergmann 提交于
      apm_bios_call() can fail, and return a status in its argument structure.
      If that status however is zero during a call from
      apm_get_power_status(), we end up using data that may have never been
      set, as reported by "gcc -Wmaybe-uninitialized":
      
        arch/x86/kernel/apm_32.c: In function ‘apm’:
        arch/x86/kernel/apm_32.c:1729:17: error: ‘bx’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
        arch/x86/kernel/apm_32.c:1835:5: error: ‘cx’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
        arch/x86/kernel/apm_32.c:1730:17: note: ‘cx’ was declared here
        arch/x86/kernel/apm_32.c:1842:27: error: ‘dx’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
        arch/x86/kernel/apm_32.c:1731:17: note: ‘dx’ was declared here
      
      This changes the function to return "APM_NO_ERROR" here, which makes the
      code more robust to broken BIOS versions, and avoids the warning.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Reviewed-by: NJiri Kosina <jkosina@suse.cz>
      Reviewed-by: NLuis R. Rodriguez <mcgrof@kernel.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      3a6d8676
  14. 11 11月, 2016 1 次提交
  15. 10 11月, 2016 2 次提交
    • S
      x86/kexec: add -fno-PIE · 90944e40
      Sebastian Andrzej Siewior 提交于
      If the gcc is configured to do -fPIE by default then the build aborts
      later with:
      | Unsupported relocation type: unknown type rel type name (29)
      
      Tagging it stable so it is possible to compile recent stable kernels as
      well.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Signed-off-by: NMichal Marek <mmarek@suse.com>
      90944e40
    • T
      x86/cpu: Deal with broken firmware (VMWare/XEN) · d49597fd
      Thomas Gleixner 提交于
      Both ACPI and MP specifications require that the APIC id in the respective
      tables must be the same as the APIC id in CPUID.
      
      The kernel retrieves the physical package id from the APIC id during the
      ACPI/MP table scan and builds the physical to logical package map. The
      physical package id which is used after a CPU comes up is retrieved from
      CPUID. So we rely on ACPI/MP tables and CPUID agreeing in that respect.
      
      There exist VMware and XEN implementations which violate the spec. As a
      result the physical to logical package map, which relies on the ACPI/MP
      tables does not work on those systems, because the CPUID initialized
      physical package id does not match the firmware id. This causes system
      crashes and malfunction due to invalid package mappings.
      
      The only way to cure this is to sanitize the physical package id after the
      CPUID enumeration and yell when the APIC ids are different. Fix up the
      initial APIC id, which is fine as it is only used printout purposes.
      
      If the physical package IDs differ yell and use the package information
      from the ACPI/MP tables so the existing logical package map just works.
      
      Chas provided the resulting dmesg output for his affected 4 virtual
      sockets, 1 core per socket VM:
      
      [Firmware Bug]: CPU1: APIC id mismatch. Firmware: 1 CPUID: 2
      [Firmware Bug]: CPU1: Using firmware package id 1 instead of 2
      ....
      
      Reported-and-tested-by: "Charles (Chas) Williams" <ciwillia@brocade.com>,
      Reported-by: NM. Vefa Bicakci <m.v.b@runbox.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Alok Kataria <akataria@vmware.com>
      Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
      Cc: #4.6+ <stable@vger,kernel.org>
      Link: http://lkml.kernel.org/r/alpine.DEB.2.20.1611091613540.3501@nanosSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      d49597fd
新手
引导
客服 返回
顶部