Skip to content
Snippets Groups Projects
  1. Jun 08, 2022
    • Linus Torvalds's avatar
      cert host tools: Stop complaining about deprecated OpenSSL functions · 6bfb56e9
      Linus Torvalds authored
      
      OpenSSL 3.0 deprecated the OpenSSL's ENGINE API.  That is as may be, but
      the kernel build host tools still use it.  Disable the warning about
      deprecated declarations until somebody who cares fixes it.
      
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      6bfb56e9
    • Linus Torvalds's avatar
      Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm · 34f4335c
      Linus Torvalds authored
      Pull KVM fixes from Paolo Bonzini:
      
       - syzkaller NULL pointer dereference
      
       - TDP MMU performance issue with disabling dirty logging
      
       - 5.14 regression with SVM TSC scaling
      
       - indefinite stall on applying live patches
      
       - unstable selftest
      
       - memory leak from wrong copy-and-paste
      
       - missed PV TLB flush when racing with emulation
      
      * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
        KVM: x86: do not report a vCPU as preempted outside instruction boundaries
        KVM: x86: do not set st->preempted when going back to user space
        KVM: SVM: fix tsc scaling cache logic
        KVM: selftests: Make hyperv_clock selftest more stable
        KVM: x86/MMU: Zap non-leaf SPTEs when disabling dirty logging
        x86: drop bogus "cc" clobber from __try_cmpxchg_user_asm()
        KVM: x86/mmu: Check every prev_roots in __kvm_mmu_free_obsolete_roots()
        entry/kvm: Exit to user mode when TIF_NOTIFY_SIGNAL is set
        KVM: Don't null dereference ops->destroy
      34f4335c
    • Linus Torvalds's avatar
      Merge tag 'tpmdd-next-v5.19-rc2-v2' of... · 32d380a7
      Linus Torvalds authored
      Merge tag 'tpmdd-next-v5.19-rc2-v2' of git://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd
      
      Pull tpm fix from Jarkko Sakkinen:
       "A bug fix for migratable (whether or not a key is tied to the TPM chip
        soldered to the machine) handling for TPM2 trusted keys"
      
      * tag 'tpmdd-next-v5.19-rc2-v2' of git://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd:
        KEYS: trusted: tpm2: Fix migratable logic
      32d380a7
    • David Safford's avatar
      KEYS: trusted: tpm2: Fix migratable logic · dda53843
      David Safford authored
      
      When creating (sealing) a new trusted key, migratable
      trusted keys have the FIXED_TPM and FIXED_PARENT attributes
      set, and non-migratable keys don't. This is backwards, and
      also causes creation to fail when creating a migratable key
      under a migratable parent. (The TPM thinks you are trying to
      seal a non-migratable blob under a migratable parent.)
      
      The following simple patch fixes the logic, and has been
      tested for all four combinations of migratable and non-migratable
      trusted keys and parent storage keys. With this logic, you will
      get a proper failure if you try to create a non-migratable
      trusted key under a migratable parent storage key, and all other
      combinations work correctly.
      
      Cc: stable@vger.kernel.org # v5.13+
      Fixes: e5fb5d2c ("security: keys: trusted: Make sealed key properly interoperable")
      Signed-off-by: default avatarDavid Safford <david.safford@gmail.com>
      Reviewed-by: default avatarAhmad Fatoum <a.fatoum@pengutronix.de>
      Reviewed-by: default avatarJarkko Sakkinen <jarkko@kernel.org>
      Signed-off-by: default avatarJarkko Sakkinen <jarkko@kernel.org>
      dda53843
    • Paolo Bonzini's avatar
      KVM: x86: do not report a vCPU as preempted outside instruction boundaries · 6cd88243
      Paolo Bonzini authored
      
      If a vCPU is outside guest mode and is scheduled out, it might be in the
      process of making a memory access.  A problem occurs if another vCPU uses
      the PV TLB flush feature during the period when the vCPU is scheduled
      out, and a virtual address has already been translated but has not yet
      been accessed, because this is equivalent to using a stale TLB entry.
      
      To avoid this, only report a vCPU as preempted if sure that the guest
      is at an instruction boundary.  A rescheduling request will be delivered
      to the host physical CPU as an external interrupt, so for simplicity
      consider any vmexit *not* instruction boundary except for external
      interrupts.
      
      It would in principle be okay to report the vCPU as preempted also
      if it is sleeping in kvm_vcpu_block(): a TLB flush IPI will incur the
      vmentry/vmexit overhead unnecessarily, and optimistic spinning is
      also unlikely to succeed.  However, leave it for later because right
      now kvm_vcpu_check_block() is doing memory accesses.  Even
      though the TLB flush issue only applies to virtual memory address,
      it's very much preferrable to be conservative.
      
      Reported-by: default avatarJann Horn <jannh@google.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      6cd88243
    • Paolo Bonzini's avatar
      KVM: x86: do not set st->preempted when going back to user space · 54aa83c9
      Paolo Bonzini authored
      
      Similar to the Xen path, only change the vCPU's reported state if the vCPU
      was actually preempted.  The reason for KVM's behavior is that for example
      optimistic spinning might not be a good idea if the guest is doing repeated
      exits to userspace; however, it is confusing and unlikely to make a difference,
      because well-tuned guests will hardly ever exit KVM_RUN in the first place.
      
      Suggested-by: default avatarSean Christopherson <seanjc@google.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      54aa83c9
  2. Jun 07, 2022
  3. Jun 06, 2022
  4. Jun 05, 2022
Loading