1. 23 Jun, 2020 4 commits
    • Sean Christopherson's avatar
      KVM: VMX: Remove vcpu_vmx's defunct copy of host_pkru · e4553b49
      Sean Christopherson authored
      Remove vcpu_vmx.host_pkru, which got left behind when PKRU support was
      moved to common x86 code.
      
      No functional change intended.
      
      Fixes: 37486135
      
       ("KVM: x86: Fix pkru save/restore when guest CR4.PKE=0, move it to x86.c")
      Signed-off-by: default avatarSean Christopherson <sean.j.christopherson@intel.com>
      Message-Id: <20200617034123.25647-1-sean.j.christopherson@intel.com>
      Reviewed-by: default avatarVitaly Kuznetsov <vkuznets@redhat.com>
      Reviewed-by: default avatarJim Mattson <jmattson@google.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      e4553b49
    • Marcelo Tosatti's avatar
      KVM: x86: allow TSC to differ by NTP correction bounds without TSC scaling · 26769f96
      Marcelo Tosatti authored
      
      
      The Linux TSC calibration procedure is subject to small variations
      (its common to see +-1 kHz difference between reboots on a given CPU, for example).
      
      So migrating a guest between two hosts with identical processor can fail, in case
      of a small variation in calibrated TSC between them.
      
      Without TSC scaling, the current kernel interface will either return an error
      (if user_tsc_khz <= tsc_khz) or enable TSC catchup mode.
      
      This change enables the following TSC tolerance check to
      accept KVM_SET_TSC_KHZ within tsc_tolerance_ppm (which is 250ppm by default).
      
              /*
               * Compute the variation in TSC rate which is acceptable
               * within the range of tolerance and decide if the
               * rate being applied is within that bounds of the hardware
               * rate.  If so, no scaling or compensation need be done.
               */
              thresh_lo = adjust_tsc_khz(tsc_khz, -tsc_tolerance_ppm);
              thresh_hi = adjust_tsc_khz(tsc_khz, tsc_tolerance_ppm);
              if (user_tsc_khz < thresh_lo || user_tsc_khz > thresh_hi) {
                      pr_debug("kvm: requested TSC rate %u falls outside tolerance [%u,%u]\n", user_tsc_khz, thresh_lo, thresh_hi);
                      use_scaling = 1;
              }
      
      NTP daemon in the guest can correct this difference (NTP can correct upto 500ppm).
      Signed-off-by: default avatarMarcelo Tosatti <mtosatti@redhat.com>
      
      Message-Id: <20200616114741.GA298183@fuller.cnet>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      26769f96
    • Xiaoyao Li's avatar
      KVM: X86: Fix MSR range of APIC registers in X2APIC mode · bf10bd0b
      Xiaoyao Li authored
      Only MSR address range 0x800 through 0x8ff is architecturally reserved
      and dedicated for accessing APIC registers in x2APIC mode.
      
      Fixes: 0105d1a5
      
       ("KVM: x2apic interface to lapic")
      Signed-off-by: default avatarXiaoyao Li <xiaoyao.li@intel.com>
      Message-Id: <20200616073307.16440-1-xiaoyao.li@intel.com>
      Cc: stable@vger.kernel.org
      Reviewed-by: default avatarSean Christopherson <sean.j.christopherson@intel.com>
      Reviewed-by: default avatarJim Mattson <jmattson@google.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      bf10bd0b
    • Sean Christopherson's avatar
      KVM: VMX: Stop context switching MSR_IA32_UMWAIT_CONTROL · bf09fb6c
      Sean Christopherson authored
      Remove support for context switching between the guest's and host's
      desired UMWAIT_CONTROL.  Propagating the guest's value to hardware isn't
      required for correct functionality, e.g. KVM intercepts reads and writes
      to the MSR, and the latency effects of the settings controlled by the
      MSR are not architecturally visible.
      
      As a general rule, KVM should not allow the guest to control power
      management settings unless explicitly enabled by userspace, e.g. see
      KVM_CAP_X86_DISABLE_EXITS.  E.g. Intel's SDM explicitly states that C0.2
      can improve the performance of SMT siblings.  A devious guest could
      disable C0.2 so as to improve the performance of their workloads at the
      detriment to workloads running in the host or on other VMs.
      
      Wholesale removal of UMWAIT_CONTROL context switching also fixes a race
      condition where updates from the host may cause KVM to enter the guest
      with the incorrect value.  Because updates are are propagated to all
      CPUs via IPI (SMP function callback), the value in hardware may be
      stale with respect to the cached value and KVM could enter the guest
      with the wrong value in hardware.  As above, the guest can't observe the
      bad value, but it's a weird and confusing wart in the implementation.
      
      Removal also fixes the unnecessary usage of VMX's atomic load/store MSR
      lists.  Using the lists is only necessary for MSRs that are required for
      correct functionality immediately upon VM-Enter/VM-Exit, e.g. EFER on
      old hardware, or for MSRs that need to-the-uop precision, e.g. perf
      related MSRs.  For UMWAIT_CONTROL, the effects are only visible in the
      kernel via TPAUSE/delay(), and KVM doesn't do any form of delay in
      vcpu_vmx_run().  Using the atomic lists is undesirable as they are more
      expensive than direct RDMSR/WRMSR.
      
      Furthermore, even if giving the guest control of the MSR is legitimate,
      e.g. in pass-through scenarios, it's not clear that the benefits would
      outweigh the overhead.  E.g. saving and restoring an MSR across a VMX
      roundtrip costs ~250 cycles, and if the guest diverged from the host
      that cost would be paid on every run of the guest.  In other words, if
      there is a legitimate use case then it should be enabled by a new
      per-VM capability.
      
      Note, KVM still needs to emulate MSR_IA32_UMWAIT_CONTROL so that it can
      correctly expose other WAITPKG features to the guest, e.g. TPAUSE,
      UMWAIT and UMONITOR.
      
      Fixes: 6e3ba4ab
      
       ("KVM: vmx: Emulate MSR IA32_UMWAIT_CONTROL")
      Cc: stable@vger.kernel.org
      Cc: Jingqi Liu <jingqi.liu@intel.com>
      Cc: Tao Xu <tao3.xu@intel.com>
      Signed-off-by: default avatarSean Christopherson <sean.j.christopherson@intel.com>
      Message-Id: <20200623005135.10414-1-sean.j.christopherson@intel.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      bf09fb6c
  2. 22 Jun, 2020 4 commits
    • Sean Christopherson's avatar
      KVM: nVMX: Plumb L2 GPA through to PML emulation · 2dbebf7a
      Sean Christopherson authored
      Explicitly pass the L2 GPA to kvm_arch_write_log_dirty(), which for all
      intents and purposes is vmx_write_pml_buffer(), instead of having the
      latter pull the GPA from vmcs.GUEST_PHYSICAL_ADDRESS.  If the dirty bit
      update is the result of KVM emulation (rare for L2), then the GPA in the
      VMCS may be stale and/or hold a completely unrelated GPA.
      
      Fixes: c5f983f6
      
       ("nVMX: Implement emulated Page Modification Logging")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarSean Christopherson <sean.j.christopherson@intel.com>
      Message-Id: <20200622215832.22090-2-sean.j.christopherson@intel.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      2dbebf7a
    • Vitaly Kuznetsov's avatar
      KVM: x86/mmu: Avoid mixing gpa_t with gfn_t in walk_addr_generic() · 312d16c7
      Vitaly Kuznetsov authored
      
      
      translate_gpa() returns a GPA, assigning it to 'real_gfn' seems obviously
      wrong. There is no real issue because both 'gpa_t' and 'gfn_t' are u64 and
      we don't use the value in 'real_gfn' as a GFN, we do
      
       real_gfn = gpa_to_gfn(real_gfn);
      
      instead. 'If you see a "buffalo" sign on an elephant's cage, do not trust
      your eyes', but let's fix it for good.
      
      No functional change intended.
      Signed-off-by: default avatarVitaly Kuznetsov <vkuznets@redhat.com>
      Message-Id: <20200622151435.752560-1-vkuznets@redhat.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      312d16c7
    • Paolo Bonzini's avatar
      KVM: LAPIC: ensure APIC map is up to date on concurrent update requests · 44d52717
      Paolo Bonzini authored
      
      
      The following race can cause lost map update events:
      
               cpu1                            cpu2
      
                                      apic_map_dirty = true
        ------------------------------------------------------------
                                      kvm_recalculate_apic_map:
                                           pass check
                                               mutex_lock(&kvm->arch.apic_map_lock);
                                               if (!kvm->arch.apic_map_dirty)
                                           and in process of updating map
        -------------------------------------------------------------
          other calls to
             apic_map_dirty = true         might be too late for affected cpu
        -------------------------------------------------------------
                                           apic_map_dirty = false
        -------------------------------------------------------------
          kvm_recalculate_apic_map:
          bail out on
            if (!kvm->arch.apic_map_dirty)
      
      To fix it, record the beginning of an update of the APIC map in
      apic_map_dirty.  If another APIC map change switches apic_map_dirty
      back to DIRTY during the update, kvm_recalculate_apic_map should not
      make it CLEAN, and the other caller will go through the slow path.
      Reported-by: default avatarIgor Mammedov <imammedo@redhat.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      44d52717
    • Igor Mammedov's avatar
      kvm: lapic: fix broken vcpu hotplug · af28dfac
      Igor Mammedov authored
      Guest fails to online hotplugged CPU with error
        smpboot: do_boot_cpu failed(-1) to wakeup CPU#4
      
      It's caused by the fact that kvm_apic_set_state(), which used to call
      recalculate_apic_map() unconditionally and pulled hotplugged CPU into
      apic map, is updating map conditionally on state changes.  In this case
      the APIC map is not considered dirty and the is not updated.
      
      Fix the issue by forcing unconditional update from kvm_apic_set_state(),
      like it used to be.
      
      Fixes: 4abaffce
      
       ("KVM: LAPIC: Recalculate apic map in batch")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarIgor Mammedov <imammedo@redhat.com>
      Message-Id: <20200622160830.426022-1-imammedo@redhat.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      af28dfac
  3. 20 Jun, 2020 1 commit
    • Christophe Leroy's avatar
      powerpc/8xx: Provide ptep_get() with 16k pages · c0e1c8c2
      Christophe Leroy authored
      READ_ONCE() now enforces atomic read, which leads to:
      
        CC      mm/gup.o
      In file included from ./include/linux/kernel.h:11:0,
                       from mm/gup.c:2:
      In function 'gup_hugepte.constprop',
          inlined from 'gup_huge_pd.isra.79' at mm/gup.c:2465:8:
      ./include/linux/compiler.h:392:38: error: call to '__compiletime_assert_222' declared with attribute error: Unsupported access size for {READ,WRITE}_ONCE().
        _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
                                            ^
      ./include/linux/compiler.h:373:4: note: in definition of macro '__compiletime_assert'
          prefix ## suffix();    \
          ^
      ./include/linux/compiler.h:392:2: note: in expansion of macro '_compiletime_assert'
        _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
        ^
      ./include/linux/compiler.h:405:2: note: in expansion of macro 'compiletime_assert'
        compiletime_assert(__native_word(t) || sizeof(t) == sizeof(long long), \
        ^
      ./include/linux/compiler.h:291:2: note: in expansion of macro 'compiletime_assert_rwonce_type'
        compiletime_assert_rwonce_type(x);    \
        ^
      mm/gup.c:2428:8: note: in expansion of macro 'READ_ONCE'
        pte = READ_ONCE(*ptep);
              ^
      In function 'gup_get_pte',
          inlined from 'gup_pte_range' at mm/gup.c:2228:9,
          inlined from 'gup_pmd_range' at mm/gup.c:2613:15,
          inlined from 'gup_pud_range' at mm/gup.c:2641:15,
          inlined from 'gup_p4d_range' at mm/gup.c:2666:15,
          inlined from 'gup_pgd_range' at mm/gup.c:2694:15,
          inlined from 'internal_get_user_pages_fast' at mm/gup.c:2795:3:
      ./include/linux/compiler.h:392:38: error: call to '__compiletime_assert_219' declared with attribute error: Unsupported access size for {READ,WRITE}_ONCE().
        _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
                                            ^
      ./include/linux/compiler.h:373:4: note: in definition of macro '__compiletime_assert'
          prefix ## suffix();    \
          ^
      ./include/linux/compiler.h:392:2: note: in expansion of macro '_compiletime_assert'
        _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
        ^
      ./include/linux/compiler.h:405:2: note: in expansion of macro 'compiletime_assert'
        compiletime_assert(__native_word(t) || sizeof(t) == sizeof(long long), \
        ^
      ./include/linux/compiler.h:291:2: note: in expansion of macro 'compiletime_assert_rwonce_type'
        compiletime_assert_rwonce_type(x);    \
        ^
      mm/gup.c:2199:9: note: in expansion of macro 'READ_ONCE'
        return READ_ONCE(*ptep);
               ^
      make[2]: *** [mm/gup.o] Error 1
      
      Define ptep_get() on 8xx when using 16k pages.
      
      Fixes: 9e343b46
      
       ("READ_ONCE: Enforce atomicity for {READ,WRITE}_ONCE() memory accesses")
      Signed-off-by: default avatarChristophe Leroy <christophe.leroy@csgroup.eu>
      Acked-by: default avatarWill Deacon <will@kernel.org>
      Acked-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Link: https://lore.kernel.org/r/341688399c1b102756046d19ea6ce39db1ae4742.1592225558.git.christophe.leroy@csgroup.eu
      c0e1c8c2
  4. 19 Jun, 2020 4 commits
  5. 18 Jun, 2020 5 commits
    • Linus Torvalds's avatar
      maccess: make get_kernel_nofault() check for minimal type compatibility · 0c389d89
      Linus Torvalds authored
      
      
      Now that we've renamed probe_kernel_address() to get_kernel_nofault()
      and made it look and behave more in line with get_user(), some of the
      subtle type behavior differences end up being more obvious and possibly
      dangerous.
      
      When you do
      
              get_user(val, user_ptr);
      
      the type of the access comes from the "user_ptr" part, and the above
      basically acts as
      
              val = *user_ptr;
      
      by design (except, of course, for the fact that the actual dereference
      is done with a user access).
      
      Note how in the above case, the type of the end result comes from the
      pointer argument, and then the value is cast to the type of 'val' as
      part of the assignment.
      
      So the type of the pointer is ultimately the more important type both
      for the access itself.
      
      But 'get_kernel_nofault()' may now _look_ similar, but it behaves very
      differently.  When you do
      
              get_kernel_nofault(val, kernel_ptr);
      
      it behaves like
      
              val = *(typeof(val) *)kernel_ptr;
      
      except, of course, for the fact that the actual dereference is done with
      exception handling so that a faulting access is suppressed and returned
      as the error code.
      
      But note how different the casting behavior of the two superficially
      similar accesses are: one does the actual access in the size of the type
      the pointer points to, while the other does the access in the size of
      the target, and ignores the pointer type entirely.
      
      Actually changing get_kernel_nofault() to act like get_user() is almost
      certainly the right thing to do eventually, but in the meantime this
      patch adds logit to at least verify that the pointer type is compatible
      with the type of the result.
      
      In many cases, this involves just casting the pointer to 'void *' to
      make it obvious that the type of the pointer is not the important part.
      It's not how 'get_user()' acts, but at least the behavioral difference
      is now obvious and explicit.
      
      Cc: Christoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      0c389d89
    • Christoph Hellwig's avatar
      maccess: rename probe_kernel_address to get_kernel_nofault · 25f12ae4
      Christoph Hellwig authored
      
      
      Better describe what this helper does, and match the naming of
      copy_from_kernel_nofault.
      
      Also switch the argument order around, so that it acts and looks
      like get_user().
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      25f12ae4
    • Will Deacon's avatar
      arm64: hw_breakpoint: Don't invoke overflow handler on uaccess watchpoints · 24ebec25
      Will Deacon authored
      Unprivileged memory accesses generated by the so-called "translated"
      instructions (e.g. STTR) at EL1 can cause EL0 watchpoints to fire
      unexpectedly if kernel debugging is enabled. In such cases, the
      hw_breakpoint logic will invoke the user overflow handler which will
      typically raise a SIGTRAP back to the current task. This is futile when
      returning back to the kernel because (a) the signal won't have been
      delivered and (b) userspace can't handle the thing anyway.
      
      Avoid invoking the user overflow handler for watchpoints triggered by
      kernel uaccess routines, and instead single-step over the faulting
      instruction as we would if no overflow handler had been installed.
      
      (Fixes tag identifies the introduction of unprivileged memory accesses,
       which exposed this latent bug in the hw_breakpoint code)
      
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: James Morse <james.morse@arm.com>
      Fixes: 57f4959b
      
       ("arm64: kernel: Add support for User Access Override")
      Reported-by: default avatarLuis Machado <luis.machado@linaro.org>
      Signed-off-by: default avatarWill Deacon <will@kernel.org>
      24ebec25
    • Gustavo A. R. Silva's avatar
      arm64: kexec_file: Use struct_size() in kmalloc() · bf508ec9
      Gustavo A. R. Silva authored
      
      
      Make use of the struct_size() helper instead of an open-coded version
      in order to avoid any potential type mistakes.
      
      This code was detected with the help of Coccinelle and, audited and
      fixed manually.
      Signed-off-by: default avatarGustavo A. R. Silva <gustavoars@kernel.org>
      Link: https://lore.kernel.org/r/20200617213407.GA1385@embeddedor
      
      Signed-off-by: default avatarWill Deacon <will@kernel.org>
      bf508ec9
    • Barry Song's avatar
      arm64: mm: reserve hugetlb CMA after numa_init · 618e0786
      Barry Song authored
      hugetlb_cma_reserve() is called at the wrong place. numa_init has not been
      done yet. so all reserved memory will be located at node0.
      
      Fixes: cf11e85f
      
       ("mm: hugetlb: optionally allocate gigantic hugepages using cma")
      Signed-off-by: default avatarBarry Song <song.bao.hua@hisilicon.com>
      Reviewed-by: default avatarAnshuman Khandual <anshuman.khandual@arm.com>
      Acked-by: default avatarRoman Gushchin <guro@fb.com>
      Cc: Matthias Brugger <matthias.bgg@gmail.com>
      Cc: Will Deacon <will@kernel.org>
      Link: https://lore.kernel.org/r/20200617215828.25296-1-song.bao.hua@hisilicon.com
      
      Signed-off-by: default avatarWill Deacon <will@kernel.org>
      618e0786
  6. 17 Jun, 2020 9 commits
    • Dmitry V. Levin's avatar
      s390: fix syscall_get_error for compat processes · b3583fca
      Dmitry V. Levin authored
      If both the tracer and the tracee are compat processes, and gprs[2]
      is assigned a value by __poke_user_compat, then the higher 32 bits
      of gprs[2] are cleared, IS_ERR_VALUE() always returns false, and
      syscall_get_error() always returns 0.
      
      Fix the implementation by sign-extending the value for compat processes
      the same way as x86 implementation does.
      
      The bug was exposed to user space by commit 201766a2 ("ptrace: add
      PTRACE_GET_SYSCALL_INFO request") and detected by strace test suite.
      
      This change fixes strace syscall tampering on s390.
      
      Link: https://lkml.kernel.org/r/20200602180051.GA2427@altlinux.org
      Fixes: 753c4dd6
      
       ("[S390] ptrace changes")
      Cc: Elvira Khabirova <lineprinter@altlinux.org>
      Cc: stable@vger.kernel.org # v2.6.28+
      Signed-off-by: default avatarDmitry V. Levin <ldv@altlinux.org>
      Signed-off-by: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: default avatarVasily Gorbik <gor@linux.ibm.com>
      b3583fca
    • Christoph Hellwig's avatar
      maccess: rename probe_user_{read,write} to copy_{from,to}_user_nofault · c0ee37e8
      Christoph Hellwig authored
      
      
      Better describe what these functions do.
      Suggested-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      c0ee37e8
    • Christoph Hellwig's avatar
      fe557319
    • Michael Ellerman's avatar
      powerpc/syscalls: Use the number when building SPU syscall table · 1497eea6
      Michael Ellerman authored
      
      
      Currently the macro that inserts entries into the SPU syscall table
      doesn't actually use the "nr" (syscall number) parameter.
      
      This does work, but it relies on the exact right number of syscall
      entries being emitted in order for the syscal numbers to line up with
      the array entries. If for example we had two entries with the same
      syscall number we wouldn't get an error, it would just cause all
      subsequent syscalls to be off by one in the spu_syscall_table.
      
      So instead change the macro to assign to the specific entry of the
      array, meaning any numbering overlap will be caught by the compiler.
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Acked-by: default avatarArnd Bergmann <arnd@arndb.de>
      Link: https://lore.kernel.org/r/20200616135617.2937252-1-mpe@ellerman.id.au
      1497eea6
    • Mike Rapoport's avatar
      powerpc/8xx: use pmd_off() to access a PMD entry in pte_update() · 687993cc
      Mike Rapoport authored
      
      
      The pte_update() implementation for PPC_8xx unfolds page table from the PGD
      level to access a PMD entry. Since 8xx has only 2-level page table this can
      be simplified with pmd_off() shortcut.
      
      Replace explicit unfolding with pmd_off() and drop defines of pgd_index()
      and pgd_offset() that are no longer needed.
      Signed-off-by: default avatarMike Rapoport <rppt@linux.ibm.com>
      Reviewed-by: default avatarChristophe Leroy <christophe.leroy@c-s.fr>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Link: https://lore.kernel.org/r/20200615092229.23142-1-rppt@kernel.org
      687993cc
    • Will Deacon's avatar
      arm64: bti: Require clang >= 10.0.1 for in-kernel BTI support · b9249cba
      Will Deacon authored
      
      
      Unfortunately, most versions of clang that support BTI are capable of
      miscompiling the kernel when converting a switch statement into a jump
      table. As an example, attempting to spawn a KVM guest results in a panic:
      
      [   56.253312] Kernel panic - not syncing: bad mode
      [   56.253834] CPU: 0 PID: 279 Comm: lkvm Not tainted 5.8.0-rc1 #2
      [   56.254225] Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015
      [   56.254712] Call trace:
      [   56.254952]  dump_backtrace+0x0/0x1d4
      [   56.255305]  show_stack+0x1c/0x28
      [   56.255647]  dump_stack+0xc4/0x128
      [   56.255905]  panic+0x16c/0x35c
      [   56.256146]  bad_el0_sync+0x0/0x58
      [   56.256403]  el1_sync_handler+0xb4/0xe0
      [   56.256674]  el1_sync+0x7c/0x100
      [   56.256928]  kvm_vm_ioctl_check_extension_generic+0x74/0x98
      [   56.257286]  __arm64_sys_ioctl+0x94/0xcc
      [   56.257569]  el0_svc_common+0x9c/0x150
      [   56.257836]  do_el0_svc+0x84/0x90
      [   56.258083]  el0_sync_handler+0xf8/0x298
      [   56.258361]  el0_sync+0x158/0x180
      
      This is because the switch in kvm_vm_ioctl_check_extension_generic()
      is executed as an indirect branch to tail-call through a jump table:
      
      ffff800010032dc8:       3869694c        ldrb    w12, [x10, x9]
      ffff800010032dcc:       8b0c096b        add     x11, x11, x12, lsl #2
      ffff800010032dd0:       d61f0160        br      x11
      
      However, where the target case uses the stack, the landing pad is elided
      due to the presence of a paciasp instruction:
      
      ffff800010032e14:       d503233f        paciasp
      ffff800010032e18:       a9bf7bfd        stp     x29, x30, [sp, #-16]!
      ffff800010032e1c:       910003fd        mov     x29, sp
      ffff800010032e20:       aa0803e0        mov     x0, x8
      ffff800010032e24:       940017c0        bl      ffff800010038d24 <kvm_vm_ioctl_check_extension>
      ffff800010032e28:       93407c00        sxtw    x0, w0
      ffff800010032e2c:       a8c17bfd        ldp     x29, x30, [sp], #16
      ffff800010032e30:       d50323bf        autiasp
      ffff800010032e34:       d65f03c0        ret
      
      Unfortunately, this results in a fatal exception because paciasp is
      compatible only with branch-and-link (call) instructions and not simple
      indirect branches.
      
      A fix is being merged into Clang 10.0.1 so that a 'bti j' instruction is
      emitted as an explicit landing pad in this situation. Make in-kernel
      BTI depend on that compiler version when building with clang.
      
      Cc: Tom Stellard <tstellar@redhat.com>
      Cc: Daniel Kiss <daniel.kiss@arm.com>
      Reviewed-by: default avatarMark Brown <broonie@kernel.org>
      Acked-by: default avatarDave Martin <Dave.Martin@arm.com>
      Reviewed-by: default avatarNathan Chancellor <natechancellor@gmail.com>
      Acked-by: default avatarNick Desaulniers <ndesaulniers@google.com>
      Link: https://lore.kernel.org/r/20200615105524.GA2694@willie-the-truck
      Link: https://lore.kernel.org/r/20200616183630.2445-1-will@kernel.org
      
      Signed-off-by: default avatarWill Deacon <will@kernel.org>
      b9249cba
    • Masahiro Yamada's avatar
      kconfig: unify cc-option and as-option · 4d0831e8
      Masahiro Yamada authored
      cc-option and as-option are almost the same; both pass the flag to
      $(CC). The main difference is the cc-option stops before the assemble
      stage (-S option) whereas as-option stops after (-c option).
      
      I chose -S because it is slightly faster, but $(cc-option,-gz=zlib)
      returns a wrong result (https://lkml.org/lkml/2020/6/9/1529).
      It has been fixed by commit 7b169944
      
       ("Makefile: Improve compressed
      debug info support detection"), but the assembler should always be
      invoked for more reliable compiler option tests.
      
      However, you cannot simply replace -S with -c because the following
      code in lib/Kconfig.debug would break:
      
          depends on $(cc-option,-gsplit-dwarf)
      
      The combination of -c and -gsplit-dwarf does not accept /dev/null as
      output.
      
        $ cat /dev/null | gcc -gsplit-dwarf -S -x c - -o /dev/null
        $ echo $?
        0
      
        $ cat /dev/null | gcc -gsplit-dwarf -c -x c - -o /dev/null
        objcopy: Warning: '/dev/null' is not an ordinary file
        $ echo $?
        1
      
        $ cat /dev/null | gcc -gsplit-dwarf -c -x c - -o tmp.o
        $ echo $?
        0
      
      There is another flag that creates an separate file based on the
      object file path:
      
        $ cat /dev/null | gcc -ftest-coverage -c -x c - -o /dev/null
        <stdin>:1: error: cannot open /dev/null.gcno
      
      So, we cannot use /dev/null to sink the output.
      
      Align the cc-option implementation with scripts/Kbuild.include.
      
      With -c option used in cc-option, as-option is unneeded.
      Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      Acked-by: default avatarWill Deacon <will@kernel.org>
      4d0831e8
    • Jiri Olsa's avatar
      kretprobe: Prevent triggering kretprobe from within kprobe_flush_task · 9b38cc70
      Jiri Olsa authored
      Ziqian reported lockup when adding retprobe on _raw_spin_lock_irqsave.
      My test was also able to trigger lockdep output:
      
       ============================================
       WARNING: possible recursive locking detected
       5.6.0-rc6+ #6 Not tainted
       --------------------------------------------
       sched-messaging/2767 is trying to acquire lock:
       ffffffff9a492798 (&(kretprobe_table_locks[i].lock)){-.-.}, at: kretprobe_hash_lock+0x52/0xa0
      
       but task is already holding lock:
       ffffffff9a491a18 (&(kretprobe_table_locks[i].lock)){-.-.}, at: kretprobe_trampoline+0x0/0x50
      
       other info that might help us debug this:
        Possible unsafe locking scenario:
      
              CPU0
              ----
         lock(&(kretprobe_table_locks[i].lock));
         lock(&(kretprobe_table_locks[i].lock));
      
        *** DEADLOCK ***
      
        May be due to missing lock nesting notation
      
       1 lock held by sched-messaging/2767:
        #0: ffffffff9a491a18 (&(kretprobe_table_locks[i].lock)){-.-.}, at: kretprobe_trampoline+0x0/0x50
      
       stack backtrace:
       CPU: 3 PID: 2767 Comm: sched-messaging Not tainted 5.6.0-rc6+ #6
       Call Trace:
        dump_stack+0x96/0xe0
        __lock_acquire.cold.57+0x173/0x2b7
        ? native_queued_spin_lock_slowpath+0x42b/0x9e0
        ? lockdep_hardirqs_on+0x590/0x590
        ? __lock_acquire+0xf63/0x4030
        lock_acquire+0x15a/0x3d0
        ? kretprobe_hash_lock+0x52/0xa0
        _raw_spin_lock_irqsave+0x36/0x70
        ? kretprobe_hash_lock+0x52/0xa0
        kretprobe_hash_lock+0x52/0xa0
        trampoline_handler+0xf8/0x940
        ? kprobe_fault_handler+0x380/0x380
        ? find_held_lock+0x3a/0x1c0
        kretprobe_trampoline+0x25/0x50
        ? lock_acquired+0x392/0xbc0
        ? _raw_spin_lock_irqsave+0x50/0x70
        ? __get_valid_kprobe+0x1f0/0x1f0
        ? _raw_spin_unlock_irqrestore+0x3b/0x40
        ? finish_task_switch+0x4b9/0x6d0
        ? __switch_to_asm+0x34/0x70
        ? __switch_to_asm+0x40/0x70
      
      The code within the kretprobe handler checks for probe reentrancy,
      so we won't trigger any _raw_spin_lock_irqsave probe in there.
      
      The problem is in outside kprobe_flush_task, where we call:
      
        kprobe_flush_task
          kretprobe_table_lock
            raw_spin_lock_irqsave
              _raw_spin_lock_irqsave
      
      where _raw_spin_lock_irqsave triggers the kretprobe and installs
      kretprobe_trampoline handler on _raw_spin_lock_irqsave return.
      
      The kretprobe_trampoline handler is then executed with already
      locked kretprobe_table_locks, and first thing it does is to
      lock kretprobe_table_locks ;-) the whole lockup path like:
      
        kprobe_flush_task
          kretprobe_table_lock
            raw_spin_lock_irqsave
              _raw_spin_lock_irqsave ---> probe triggered, kretprobe_trampoline installed
      
              ---> kretprobe_table_locks locked
      
              kretprobe_trampoline
                trampoline_handler
                  kretprobe_hash_lock(current, &head, &flags);  <--- deadlock
      
      Adding kprobe_busy_begin/end helpers that mark code with fake
      probe installed to prevent triggering of another kprobe within
      this code.
      
      Using these helpers in kprobe_flush_task, so the probe recursion
      protection check is hit and the probe is never set to prevent
      above lockup.
      
      Link: http://lkml.kernel.org/r/158927059835.27680.7011202830041561604.stgit@devnote2
      
      Fixes: ef53d9c5
      
       ("kprobes: improve kretprobe scalability with hashed locking")
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: "Gustavo A . R . Silva" <gustavoars@kernel.org>
      Cc: Anders Roxell <anders.roxell@linaro.org>
      Cc: "Naveen N . Rao" <naveen.n.rao@linux.ibm.com>
      Cc: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
      Cc: David Miller <davem@davemloft.net>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: stable@vger.kernel.org
      Reported-by: default avatar"Ziqian SUN (Zamir)" <zsun@redhat.com>
      Acked-by: default avatarMasami Hiramatsu <mhiramat@kernel.org>
      Signed-off-by: default avatarJiri Olsa <jolsa@kernel.org>
      Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      9b38cc70
    • Arvind Sankar's avatar
      x86/purgatory: Add -fno-stack-protector · ff58155c
      Arvind Sankar authored
      The purgatory Makefile removes -fstack-protector options if they were
      configured in, but does not currently add -fno-stack-protector.
      
      If gcc was configured with the --enable-default-ssp configure option,
      this results in the stack protector still being enabled for the
      purgatory (absent distro-specific specs files that might disable it
      again for freestanding compilations), if the main kernel is being
      compiled with stack protection enabled (if it's disabled for the main
      kernel, the top-level Makefile will add -fno-stack-protector).
      
      This will break the build since commit
        e4160b2e
      
       ("x86/purgatory: Fail the build if purgatory.ro has missing symbols")
      and prior to that would have caused runtime failure when trying to use
      kexec.
      
      Explicitly add -fno-stack-protector to avoid this, as done in other
      Makefiles that need to disable the stack protector.
      Reported-by: default avatarGabriel C <nix.or.die@googlemail.com>
      Signed-off-by: default avatarArvind Sankar <nivedita@alum.mit.edu>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      ff58155c
  7. 16 Jun, 2020 13 commits