1. 14 Mar, 2020 5 commits
    • Paolo Bonzini's avatar
      018cabb6
    • Vitaly Kuznetsov's avatar
      KVM: nVMX: avoid NULL pointer dereference with incorrect EVMCS GPAs · 95fa1010
      Vitaly Kuznetsov authored
      When an EVMCS enabled L1 guest on KVM will tries doing enlightened VMEnter
      with EVMCS GPA = 0 the host crashes because the
      
      evmcs_gpa != vmx->nested.hv_evmcs_vmptr
      
      condition in nested_vmx_handle_enlightened_vmptrld() will evaluate to
      false (as nested.hv_evmcs_vmptr is zeroed after init). The crash will
      happen on vmx->nested.hv_evmcs pointer dereference.
      
      Another problematic EVMCS ptr value is '-1' but it only causes host crash
      after nested_release_evmcs() invocation. The problem is exactly the same as
      with '0', we mistakenly think that the EVMCS pointer hasn't changed and
      thus nested.hv_evmcs_vmptr is valid.
      
      Resolve the issue by adding an additional !vmx->nested.hv_evmcs
      check to nested_vmx_handle_enlightened_vmptrld(), this way we will
      always be trying kvm_vcpu_map() when nested.hv_evmcs is NULL
      and this is supposed to catch all invalid EVMCS GPAs.
      
      Also, initialize hv_evmcs_vmptr to '0' in nested_release_evmcs()
      to be consistent with initialization where we don't currently
      set hv_evmcs_vmptr to '-1'.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarVitaly Kuznetsov <vkuznets@redhat.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      95fa1010
    • Paolo Bonzini's avatar
      Merge tag 'kvm-s390-master-5.6-1' of... · 997224fe
      Paolo Bonzini authored
      Merge tag 'kvm-s390-master-5.6-1' of git://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux into kvm-master
      
      KVM: s390: Fully do the CPU resets as intended
      
      With 7de3f142 ("KVM: s390: Add new reset vcpu API") we clarified
      the meaning of the reset ioctl to fully reset the CPU and not only the
      parts that can not be handled by userspace. Turns out that we missed
      some parts.
      997224fe
    • Nitesh Narayan Lal's avatar
      KVM: x86: Initializing all kvm_lapic_irq fields in ioapic_write_indirect · 0c22056f
      Nitesh Narayan Lal authored
      Previously all fields of structure kvm_lapic_irq were not initialized
      before it was passed to kvm_bitmap_or_dest_vcpus(). Which will cause
      an issue when any of those fields are used for processing a request.
      For example not initializing the msi_redir_hint field before passing
      to the kvm_bitmap_or_dest_vcpus(), may lead to a misbehavior of
      kvm_apic_map_get_dest_lapic(). This will specifically happen when the
      kvm_lowest_prio_delivery() returns TRUE due to a non-zero garbage
      value of msi_redir_hint, which should not happen as the request belongs
      to APIC fixed delivery mode and we do not want to deliver the
      interrupt only to the lowest priority candidate.
      
      This patch initializes all the fields of kvm_lapic_irq based on the
      values of ioapic redirect_entry object before passing it on to
      kvm_bitmap_or_dest_vcpus().
      
      Fixes: 7ee30bc1 ("KVM: x86: deliver KVM IOAPIC scan request to target vCPUs")
      Signed-off-by: default avatarNitesh Narayan Lal <nitesh@redhat.com>
      Reviewed-by: default avatarVitaly Kuznetsov <vkuznets@redhat.com>
      [Set level to false since the value doesn't really matter. Suggested
       by Vitaly Kuznetsov. - Paolo]
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      0c22056f
    • Sean Christopherson's avatar
      KVM: VMX: Condition ENCLS-exiting enabling on CPU support for SGX1 · 7a57c09b
      Sean Christopherson authored
      Enable ENCLS-exiting (and thus set vmcs.ENCLS_EXITING_BITMAP) only if
      the CPU supports SGX1.  Per Intel's SDM, all ENCLS leafs #UD if SGX1
      is not supported[*], i.e. intercepting ENCLS to inject a #UD is
      unnecessary.
      
      Avoiding ENCLS-exiting even when it is reported as supported by the CPU
      works around a reported issue where SGX is "hard" disabled after an S3
      suspend/resume cycle, i.e. CPUID.0x7.SGX=0 and the VMCS field/control
      are enumerated as unsupported.  While the root cause of the S3 issue is
      unknown, it's definitely _not_ a KVM (or kernel) bug, i.e. this is a
      workaround for what is most likely a hardware or firmware issue.  As a
      bonus side effect, KVM saves a VMWRITE when first preparing vmcs01 and
      vmcs02.
      
      Note, SGX must be disabled in BIOS to take advantage of this workaround
      
      [*] The additional ENCLS CPUID check on SGX1 exists so that SGX can be
          globally "soft" disabled post-reset, e.g. if #MC bits in MCi_CTL are
          cleared.  Soft disabled meaning disabling SGX without clearing the
          primary CPUID bit (in leaf 0x7) and without poking into non-SGX
          CPU paths, e.g. for the VMCS controls.
      
      Fixes: 0b665d30 ("KVM: vmx: Inject #UD for SGX ENCLS instruction in guest")
      Reported-by: default avatarToni Spets <toni.spets@iki.fi>
      Signed-off-by: default avatarSean Christopherson <sean.j.christopherson@intel.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      7a57c09b
  2. 11 Mar, 2020 1 commit
  3. 05 Mar, 2020 1 commit
  4. 03 Mar, 2020 2 commits
  5. 02 Mar, 2020 2 commits
    • Haiwei Li's avatar
      KVM: SVM: Fix the svm vmexit code for WRMSR · aaca2100
      Haiwei Li authored
      In svm, exit_code for MSR writes is not EXIT_REASON_MSR_WRITE which
      belongs to vmx.
      
      According to amd manual, SVM_EXIT_MSR(7ch) is the exit_code of VMEXIT_MSR
      due to RDMSR or WRMSR access to protected MSR. Additionally, the processor
      indicates in the VMCB's EXITINFO1 whether a RDMSR(EXITINFO1=0) or
      WRMSR(EXITINFO1=1) was intercepted.
      Signed-off-by: default avatarHaiwei Li <lihaiwei@tencent.com>
      Fixes: 1e9e2622 ("KVM: VMX: FIXED+PHYSICAL mode single target IPI fastpath", 2019-11-21)
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      aaca2100
    • Wanpeng Li's avatar
      KVM: X86: Fix dereference null cpufreq policy · 9a11997e
      Wanpeng Li authored
      Naresh Kamboju reported:
      
         Linux version 5.6.0-rc4 (oe-user@oe-host) (gcc version
        (GCC)) #1 SMP Sun Mar 1 22:59:08 UTC 2020
         kvm: no hardware support
         BUG: kernel NULL pointer dereference, address: 000000000000028c
         #PF: supervisor read access in kernel mode
         #PF: error_code(0x0000) - not-present page
         PGD 0 P4D 0
         Oops: 0000 [#1] SMP NOPTI
         CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.6.0-rc4 #1
         Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
        04/01/2014
         RIP: 0010:kobject_put+0x12/0x1c0
         Call Trace:
          cpufreq_cpu_put+0x15/0x20
          kvm_arch_init+0x1f6/0x2b0
          kvm_init+0x31/0x290
          ? svm_check_processor_compat+0xd/0xd
          ? svm_check_processor_compat+0xd/0xd
          svm_init+0x21/0x23
          do_one_initcall+0x61/0x2f0
          ? rdinit_setup+0x30/0x30
          ? rcu_read_lock_sched_held+0x4f/0x80
          kernel_init_freeable+0x219/0x279
          ? rest_init+0x250/0x250
          kernel_init+0xe/0x110
          ret_from_fork+0x27/0x50
         Modules linked in:
         CR2: 000000000000028c
         ---[ end trace 239abf40c55c409b ]---
         RIP: 0010:kobject_put+0x12/0x1c0
      
      cpufreq policy which is get by cpufreq_cpu_get() can be NULL if it is failure,
      this patch takes care of it.
      
      Fixes: aaec7c03 (KVM: x86: avoid useless copy of cpufreq policy)
      Reported-by: default avatarNaresh Kamboju <naresh.kamboju@linaro.org>
      Cc: Naresh Kamboju <naresh.kamboju@linaro.org>
      Signed-off-by: default avatarWanpeng Li <wanpengli@tencent.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      9a11997e
  6. 01 Mar, 2020 1 commit
  7. 28 Feb, 2020 9 commits
  8. 24 Feb, 2020 1 commit
  9. 23 Feb, 2020 5 commits
  10. 22 Feb, 2020 3 commits
  11. 21 Feb, 2020 8 commits
  12. 20 Feb, 2020 2 commits