1. 13 11月, 2019 18 次提交
  2. 06 11月, 2019 5 次提交
    • T
      perf/x86/amd: Change/fix NMI latency mitigation to use a timestamp · a1112c46
      Tom Lendacky 提交于
      [ Upstream commit df4d29732fdad43a51284f826bec3e6ded177540 ]
      
      It turns out that the NMI latency workaround from commit:
      
        6d3edaae16c6 ("x86/perf/amd: Resolve NMI latency issues for active PMCs")
      
      ends up being too conservative and results in the perf NMI handler claiming
      NMIs too easily on AMD hardware when the NMI watchdog is active.
      
      This has an impact, for example, on the hpwdt (HPE watchdog timer) module.
      This module can produce an NMI that is used to reset the system. It
      registers an NMI handler for the NMI_UNKNOWN type and relies on the fact
      that nothing has claimed an NMI so that its handler will be invoked when
      the watchdog device produces an NMI. After the referenced commit, the
      hpwdt module is unable to process its generated NMI if the NMI watchdog is
      active, because the current NMI latency mitigation results in the NMI
      being claimed by the perf NMI handler.
      
      Update the AMD perf NMI latency mitigation workaround to, instead, use a
      window of time. Whenever a PMC is handled in the perf NMI handler, set a
      timestamp which will act as a perf NMI window. Any NMIs arriving within
      that window will be claimed by perf. Anything outside that window will
      not be claimed by perf. The value for the NMI window is set to 100 msecs.
      This is a conservative value that easily covers any NMI latency in the
      hardware. While this still results in a window in which the hpwdt module
      will not receive its NMI, the window is now much, much smaller.
      Signed-off-by: NTom Lendacky <thomas.lendacky@amd.com>
      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: Borislav Petkov <bp@alien8.de>
      Cc: Jerry Hoemann <jerry.hoemann@hpe.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Fixes: 6d3edaae16c6 ("x86/perf/amd: Resolve NMI latency issues for active PMCs")
      Link: https://lkml.kernel.org/r/Message-ID:
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      a1112c46
    • K
      x86/cpu: Add Comet Lake to the Intel CPU models header · 58d33d4a
      Kan Liang 提交于
      [ Upstream commit 8d7c6ac3b2371eb1cbc9925a88f4d10efff374de ]
      
      Comet Lake is the new 10th Gen Intel processor. Add two new CPU model
      numbers to the Intel family list.
      
      The CPU model numbers are not published in the SDM yet but they come
      from an authoritative internal source.
      
       [ bp: Touch up commit message. ]
      Signed-off-by: NKan Liang <kan.liang@linux.intel.com>
      Signed-off-by: NBorislav Petkov <bp@suse.de>
      Reviewed-by: NTony Luck <tony.luck@intel.com>
      Cc: ak@linux.intel.com
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: x86-ml <x86@kernel.org>
      Link: https://lkml.kernel.org/r/1570549810-25049-2-git-send-email-kan.liang@linux.intel.comSigned-off-by: NSasha Levin <sashal@kernel.org>
      58d33d4a
    • B
      x86/xen: Return from panic notifier · af140367
      Boris Ostrovsky 提交于
      [ Upstream commit c6875f3aacf2a5a913205accddabf0bfb75cac76 ]
      
      Currently execution of panic() continues until Xen's panic notifier
      (xen_panic_event()) is called at which point we make a hypercall that
      never returns.
      
      This means that any notifier that is supposed to be called later as
      well as significant part of panic() code (such as pstore writes from
      kmsg_dump()) is never executed.
      
      There is no reason for xen_panic_event() to be this last point in
      execution since panic()'s emergency_restart() will call into
      xen_emergency_restart() from where we can perform our hypercall.
      
      Nevertheless, we will provide xen_legacy_crash boot option that will
      preserve original behavior during crash. This option could be used,
      for example, if running kernel dumper (which happens after panic
      notifiers) is undesirable.
      Reported-by: NJames Dingwall <james@dingwall.me.uk>
      Signed-off-by: NBoris Ostrovsky <boris.ostrovsky@oracle.com>
      Reviewed-by: NJuergen Gross <jgross@suse.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      af140367
    • D
      efi/x86: Do not clean dummy variable in kexec path · 9b7591cf
      Dave Young 提交于
      [ Upstream commit 2ecb7402cfc7f22764e7bbc80790e66eadb20560 ]
      
      kexec reboot fails randomly in UEFI based KVM guest.  The firmware
      just resets while calling efi_delete_dummy_variable();  Unfortunately
      I don't know how to debug the firmware, it is also possible a potential
      problem on real hardware as well although nobody reproduced it.
      
      The intention of the efi_delete_dummy_variable is to trigger garbage collection
      when entering virtual mode.  But SetVirtualAddressMap can only run once
      for each physical reboot, thus kexec_enter_virtual_mode() is not necessarily
      a good place to clean a dummy object.
      
      Drop the efi_delete_dummy_variable so that kexec reboot can work.
      Signed-off-by: NDave Young <dyoung@redhat.com>
      Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Acked-by: NMatthew Garrett <mjg59@google.com>
      Cc: Ben Dooks <ben.dooks@codethink.co.uk>
      Cc: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
      Cc: Jerry Snitselaar <jsnitsel@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Lukas Wunner <lukas@wunner.de>
      Cc: Lyude Paul <lyude@redhat.com>
      Cc: Octavian Purdila <octavian.purdila@intel.com>
      Cc: Peter Jones <pjones@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Scott Talbert <swt@techie.net>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-efi@vger.kernel.org
      Cc: linux-integrity@vger.kernel.org
      Link: https://lkml.kernel.org/r/20191002165904.8819-8-ard.biesheuvel@linaro.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      9b7591cf
    • K
      x86/cpu: Add Atom Tremont (Jacobsville) · b5b3bb03
      Kan Liang 提交于
      [ Upstream commit 00ae831dfe4474ef6029558f5eb3ef0332d80043 ]
      
      Add the Atom Tremont model number to the Intel family list.
      
      [ Tony: Also update comment at head of file to say "_X" suffix is
        also used for microserver parts. ]
      Signed-off-by: NKan Liang <kan.liang@linux.intel.com>
      Signed-off-by: NQiuxu Zhuo <qiuxu.zhuo@intel.com>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      Signed-off-by: NBorislav Petkov <bp@suse.de>
      Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
      Cc: Aristeu Rozanski <aris@redhat.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: linux-edac <linux-edac@vger.kernel.org>
      Cc: Mauro Carvalho Chehab <mchehab@s-opensource.com>
      Cc: Megha Dey <megha.dey@linux.intel.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Qiuxu Zhuo <qiuxu.zhuo@intel.com>
      Cc: Rajneesh Bhardwaj <rajneesh.bhardwaj@intel.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: x86-ml <x86@kernel.org>
      Link: https://lkml.kernel.org/r/20190125195902.17109-4-tony.luck@intel.comSigned-off-by: NSasha Levin <sashal@kernel.org>
      b5b3bb03
  3. 29 10月, 2019 3 次提交
    • S
      x86/apic/x2apic: Fix a NULL pointer deref when handling a dying cpu · 4dedaa73
      Sean Christopherson 提交于
      commit 7a22e03b0c02988e91003c505b34d752a51de344 upstream.
      
      Check that the per-cpu cluster mask pointer has been set prior to
      clearing a dying cpu's bit.  The per-cpu pointer is not set until the
      target cpu reaches smp_callin() during CPUHP_BRINGUP_CPU, whereas the
      teardown function, x2apic_dead_cpu(), is associated with the earlier
      CPUHP_X2APIC_PREPARE.  If an error occurs before the cpu is awakened,
      e.g. if do_boot_cpu() itself fails, x2apic_dead_cpu() will dereference
      the NULL pointer and cause a panic.
      
        smpboot: do_boot_cpu failed(-22) to wakeup CPU#1
        BUG: kernel NULL pointer dereference, address: 0000000000000008
        RIP: 0010:x2apic_dead_cpu+0x1a/0x30
        Call Trace:
         cpuhp_invoke_callback+0x9a/0x580
         _cpu_up+0x10d/0x140
         do_cpu_up+0x69/0xb0
         smp_init+0x63/0xa9
         kernel_init_freeable+0xd7/0x229
         ? rest_init+0xa0/0xa0
         kernel_init+0xa/0x100
         ret_from_fork+0x35/0x40
      
      Fixes: 023a6117 ("x86/apic/x2apic: Simplify cluster management")
      Signed-off-by: NSean Christopherson <sean.j.christopherson@intel.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: stable@vger.kernel.org
      Link: https://lkml.kernel.org/r/20191001205019.5789-1-sean.j.christopherson@intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4dedaa73
    • S
      x86/boot/64: Make level2_kernel_pgt pages invalid outside kernel area · 17099172
      Steve Wahl 提交于
      commit 2aa85f246c181b1fa89f27e8e20c5636426be624 upstream.
      
      Our hardware (UV aka Superdome Flex) has address ranges marked
      reserved by the BIOS. Access to these ranges is caught as an error,
      causing the BIOS to halt the system.
      
      Initial page tables mapped a large range of physical addresses that
      were not checked against the list of BIOS reserved addresses, and
      sometimes included reserved addresses in part of the mapped range.
      Including the reserved range in the map allowed processor speculative
      accesses to the reserved range, triggering a BIOS halt.
      
      Used early in booting, the page table level2_kernel_pgt addresses 1
      GiB divided into 2 MiB pages, and it was set up to linearly map a full
       1 GiB of physical addresses that included the physical address range
      of the kernel image, as chosen by KASLR.  But this also included a
      large range of unused addresses on either side of the kernel image.
      And unlike the kernel image's physical address range, this extra
      mapped space was not checked against the BIOS tables of usable RAM
      addresses.  So there were times when the addresses chosen by KASLR
      would result in processor accessible mappings of BIOS reserved
      physical addresses.
      
      The kernel code did not directly access any of this extra mapped
      space, but having it mapped allowed the processor to issue speculative
      accesses into reserved memory, causing system halts.
      
      This was encountered somewhat rarely on a normal system boot, and much
      more often when starting the crash kernel if "crashkernel=512M,high"
      was specified on the command line (this heavily restricts the physical
      address of the crash kernel, in our case usually within 1 GiB of
      reserved space).
      
      The solution is to invalidate the pages of this table outside the kernel
      image's space before the page table is activated. It fixes this problem
      on our hardware.
      
       [ bp: Touchups. ]
      Signed-off-by: NSteve Wahl <steve.wahl@hpe.com>
      Signed-off-by: NBorislav Petkov <bp@suse.de>
      Acked-by: NDave Hansen <dave.hansen@linux.intel.com>
      Acked-by: NKirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Cc: Baoquan He <bhe@redhat.com>
      Cc: Brijesh Singh <brijesh.singh@amd.com>
      Cc: dimitri.sivanich@hpe.com
      Cc: Feng Tang <feng.tang@intel.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Jordan Borgner <mail@jordan-borgner.de>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: mike.travis@hpe.com
      Cc: russ.anderson@hpe.com
      Cc: stable@vger.kernel.org
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: x86-ml <x86@kernel.org>
      Cc: Zhenzhong Duan <zhenzhong.duan@oracle.com>
      Link: https://lkml.kernel.org/r/9c011ee51b081534a7a15065b1681d200298b530.1569358539.git.steve.wahl@hpe.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      17099172
    • R
      xen/efi: Set nonblocking callbacks · 90a886b6
      Ross Lagerwall 提交于
      [ Upstream commit df359f0d09dc029829b66322707a2f558cb720f7 ]
      
      Other parts of the kernel expect these nonblocking EFI callbacks to
      exist and crash when running under Xen. Since the implementations of
      xen_efi_set_variable() and xen_efi_query_variable_info() do not take any
      locks, use them for the nonblocking callbacks too.
      Signed-off-by: NRoss Lagerwall <ross.lagerwall@citrix.com>
      Reviewed-by: NJuergen Gross <jgross@suse.com>
      Signed-off-by: NJuergen Gross <jgross@suse.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      90a886b6
  4. 18 10月, 2019 1 次提交
  5. 12 10月, 2019 4 次提交
    • S
      KVM: nVMX: Fix consistency check on injected exception error code · 63bb8b76
      Sean Christopherson 提交于
      [ Upstream commit 567926cca99ba1750be8aae9c4178796bf9bb90b ]
      
      Current versions of Intel's SDM incorrectly state that "bits 31:15 of
      the VM-Entry exception error-code field" must be zero.  In reality, bits
      31:16 must be zero, i.e. error codes are 16-bit values.
      
      The bogus error code check manifests as an unexpected VM-Entry failure
      due to an invalid code field (error number 7) in L1, e.g. when injecting
      a #GP with error_code=0x9f00.
      
      Nadav previously reported the bug[*], both to KVM and Intel, and fixed
      the associated kvm-unit-test.
      
      [*] https://patchwork.kernel.org/patch/11124749/Reported-by: NNadav Amit <namit@vmware.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NSean Christopherson <sean.j.christopherson@intel.com>
      Reviewed-by: NJim Mattson <jmattson@google.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      63bb8b76
    • A
      x86/purgatory: Disable the stackleak GCC plugin for the purgatory · 9dabade5
      Arvind Sankar 提交于
      [ Upstream commit ca14c996afe7228ff9b480cf225211cc17212688 ]
      
      Since commit:
      
        b059f801a937 ("x86/purgatory: Use CFLAGS_REMOVE rather than reset KBUILD_CFLAGS")
      
      kexec breaks if GCC_PLUGIN_STACKLEAK=y is enabled, as the purgatory
      contains undefined references to stackleak_track_stack.
      
      Attempting to load a kexec kernel results in this failure:
      
        kexec: Undefined symbol: stackleak_track_stack
        kexec-bzImage64: Loading purgatory failed
      
      Fix this by disabling the stackleak plugin for the purgatory.
      Signed-off-by: NArvind Sankar <nivedita@alum.mit.edu>
      Reviewed-by: NNick Desaulniers <ndesaulniers@google.com>
      Cc: Borislav Petkov <bp@alien8.de>
      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>
      Fixes: b059f801a937 ("x86/purgatory: Use CFLAGS_REMOVE rather than reset KBUILD_CFLAGS")
      Link: https://lkml.kernel.org/r/20190923171753.GA2252517@rani.riverdale.lanSigned-off-by: NIngo Molnar <mingo@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      9dabade5
    • J
      KVM: nVMX: handle page fault in vmread fix · eff3a54a
      Jack Wang 提交于
      During backport f7eea636c3d5 ("KVM: nVMX: handle page fault in vmread"),
      there was a mistake the exception reference should be passed to function
      kvm_write_guest_virt_system, instead of NULL, other wise, we will get
      NULL pointer deref, eg
      
      kvm-unit-test triggered a NULL pointer deref below:
      [  948.518437] kvm [24114]: vcpu0, guest rIP: 0x407ef9 kvm_set_msr_common: MSR_IA32_DEBUGCTLMSR 0x3, nop
      [  949.106464] BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
      [  949.106707] PGD 0 P4D 0
      [  949.106872] Oops: 0002 [#1] SMP
      [  949.107038] CPU: 2 PID: 24126 Comm: qemu-2.7 Not tainted 4.19.77-pserver #4.19.77-1+feature+daily+update+20191005.1625+a4168bb~deb9
      [  949.107283] Hardware name: Dell Inc. Precision Tower 3620/09WH54, BIOS 2.7.3 01/31/2018
      [  949.107549] RIP: 0010:kvm_write_guest_virt_system+0x12/0x40 [kvm]
      [  949.107719] Code: c0 5d 41 5c 41 5d 41 5e 83 f8 03 41 0f 94 c0 41 c1 e0 02 e9 b0 ed ff ff 0f 1f 44 00 00 48 89 f0 c6 87 59 56 00 00 01 48 89 d6 <49> c7 00 00 00 00 00 89 ca 49 c7 40 08 00 00 00 00 49 c7 40 10 00
      [  949.108044] RSP: 0018:ffffb31b0a953cb0 EFLAGS: 00010202
      [  949.108216] RAX: 000000000046b4d8 RBX: ffff9e9f415b0000 RCX: 0000000000000008
      [  949.108389] RDX: ffffb31b0a953cc0 RSI: ffffb31b0a953cc0 RDI: ffff9e9f415b0000
      [  949.108562] RBP: 00000000d2e14928 R08: 0000000000000000 R09: 0000000000000000
      [  949.108733] R10: 0000000000000000 R11: 0000000000000000 R12: ffffffffffffffc8
      [  949.108907] R13: 0000000000000002 R14: ffff9e9f4f26f2e8 R15: 0000000000000000
      [  949.109079] FS:  00007eff8694c700(0000) GS:ffff9e9f51a80000(0000) knlGS:0000000031415928
      [  949.109318] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  949.109495] CR2: 0000000000000000 CR3: 00000003be53b002 CR4: 00000000003626e0
      [  949.109671] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [  949.109845] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      [  949.110017] Call Trace:
      [  949.110186]  handle_vmread+0x22b/0x2f0 [kvm_intel]
      [  949.110356]  ? vmexit_fill_RSB+0xc/0x30 [kvm_intel]
      [  949.110549]  kvm_arch_vcpu_ioctl_run+0xa98/0x1b30 [kvm]
      [  949.110725]  ? kvm_vcpu_ioctl+0x388/0x5d0 [kvm]
      [  949.110901]  kvm_vcpu_ioctl+0x388/0x5d0 [kvm]
      [  949.111072]  do_vfs_ioctl+0xa2/0x620
      Signed-off-by: NJack Wang <jinpu.wang@cloud.ionos.com>
      Acked-by: NPaolo Bonzini <pbonzini@redhat.com>
      eff3a54a
    • W
      KVM: X86: Fix userspace set invalid CR4 · 21874027
      Wanpeng Li 提交于
      commit 3ca94192278ca8de169d78c085396c424be123b3 upstream.
      
      Reported by syzkaller:
      
      	WARNING: CPU: 0 PID: 6544 at /home/kernel/data/kvm/arch/x86/kvm//vmx/vmx.c:4689 handle_desc+0x37/0x40 [kvm_intel]
      	CPU: 0 PID: 6544 Comm: a.out Tainted: G           OE     5.3.0-rc4+ #4
      	RIP: 0010:handle_desc+0x37/0x40 [kvm_intel]
      	Call Trace:
      	 vmx_handle_exit+0xbe/0x6b0 [kvm_intel]
      	 vcpu_enter_guest+0x4dc/0x18d0 [kvm]
      	 kvm_arch_vcpu_ioctl_run+0x407/0x660 [kvm]
      	 kvm_vcpu_ioctl+0x3ad/0x690 [kvm]
      	 do_vfs_ioctl+0xa2/0x690
      	 ksys_ioctl+0x6d/0x80
      	 __x64_sys_ioctl+0x1a/0x20
      	 do_syscall_64+0x74/0x720
      	 entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      When CR4.UMIP is set, guest should have UMIP cpuid flag. Current
      kvm set_sregs function doesn't have such check when userspace inputs
      sregs values. SECONDARY_EXEC_DESC is enabled on writes to CR4.UMIP
      in vmx_set_cr4 though guest doesn't have UMIP cpuid flag. The testcast
      triggers handle_desc warning when executing ltr instruction since
      guest architectural CR4 doesn't set UMIP. This patch fixes it by
      adding valid CR4 and CPUID combination checking in __set_sregs.
      
      syzkaller source: https://syzkaller.appspot.com/x/repro.c?x=138efb99600000
      
      Reported-by: syzbot+0f1819555fbdce992df9@syzkaller.appspotmail.com
      Cc: stable@vger.kernel.org
      Signed-off-by: NWanpeng Li <wanpengli@tencent.com>
      Reviewed-by: NSean Christopherson <sean.j.christopherson@intel.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      21874027
  6. 05 10月, 2019 9 次提交