1. 05 2月, 2015 1 次提交
  2. 03 2月, 2015 1 次提交
  3. 29 1月, 2015 3 次提交
  4. 21 1月, 2015 2 次提交
    • B
      kvm: Fix CR3_PCID_INVD type on 32-bit · cfaa790a
      Borislav Petkov 提交于
      arch/x86/kvm/emulate.c: In function ‘check_cr_write’:
      arch/x86/kvm/emulate.c:3552:4: warning: left shift count >= width of type
          rsvd = CR3_L_MODE_RESERVED_BITS & ~CR3_PCID_INVD;
      
      happens because sizeof(UL) on 32-bit is 4 bytes but we shift it 63 bits
      to the left.
      Signed-off-by: NBorislav Petkov <bp@suse.de>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      cfaa790a
    • M
      KVM: x86: workaround SuSE's 2.6.16 pvclock vs masterclock issue · 54750f2c
      Marcelo Tosatti 提交于
      SuSE's 2.6.16 kernel fails to boot if the delta between tsc_timestamp
      and rdtsc is larger than a given threshold:
      
       * If we get more than the below threshold into the future, we rerequest
       * the real time from the host again which has only little offset then
       * that we need to adjust using the TSC.
       *
       * For now that threshold is 1/5th of a jiffie. That should be good
       * enough accuracy for completely broken systems, but also give us swing
       * to not call out to the host all the time.
       */
      #define PVCLOCK_DELTA_MAX ((1000000000ULL / HZ) / 5)
      
      Disable masterclock support (which increases said delta) in case the
      boot vcpu does not use MSR_KVM_SYSTEM_TIME_NEW.
      
      Upstreams kernels which support pvclock vsyscalls (and therefore make
      use of PVCLOCK_STABLE_BIT) use MSR_KVM_SYSTEM_TIME_NEW.
      Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      54750f2c
  5. 16 1月, 2015 1 次提交
  6. 09 1月, 2015 2 次提交
  7. 18 12月, 2014 1 次提交
  8. 05 12月, 2014 2 次提交
  9. 24 11月, 2014 3 次提交
  10. 22 11月, 2014 1 次提交
  11. 14 11月, 2014 1 次提交
  12. 07 11月, 2014 2 次提交
  13. 03 11月, 2014 2 次提交
    • N
      KVM: vmx: Unavailable DR4/5 is checked before CPL · 16f8a6f9
      Nadav Amit 提交于
      If DR4/5 is accessed when it is unavailable (since CR4.DE is set), then #UD
      should be generated even if CPL>0. This is according to Intel SDM Table 6-2:
      "Priority Among Simultaneous Exceptions and Interrupts".
      
      Note, that this may happen on the first DR access, even if the host does not
      sets debug breakpoints. Obviously, it occurs when the host debugs the guest.
      
      This patch moves the DR4/5 checks from __kvm_set_dr/_kvm_get_dr to handle_dr.
      The emulator already checks DR4/5 availability in check_dr_read. Nested
      virutalization related calls to kvm_set_dr/kvm_get_dr would not like to inject
      exceptions to the guest.
      
      As for SVM, the patch follows the previous logic as much as possible. Anyhow,
      it appears the DR interception code might be buggy - even if the DR access
      may cause an exception, the instruction is skipped.
      Signed-off-by: NNadav Amit <namit@cs.technion.ac.il>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      16f8a6f9
    • N
      KVM: x86: some apic broadcast modes does not work · 394457a9
      Nadav Amit 提交于
      KVM does not deliver x2APIC broadcast messages with physical mode.  Intel SDM
      (10.12.9 ICR Operation in x2APIC Mode) states: "A destination ID value of
      FFFF_FFFFH is used for broadcast of interrupts in both logical destination and
      physical destination modes."
      
      In addition, the local-apic enables cluster mode broadcast. As Intel SDM
      10.6.2.2 says: "Broadcast to all local APICs is achieved by setting all
      destination bits to one." This patch enables cluster mode broadcast.
      
      The fix tries to combine broadcast in different modes through a unified code.
      
      One rare case occurs when the source of IPI has its APIC disabled.  In such
      case, the source can still issue IPIs, but since the source is not obliged to
      have the same LAPIC mode as the enabled ones, we cannot rely on it.
      Since it is a rare case, it is unoptimized and done on the slow-path.
      Signed-off-by: NNadav Amit <namit@cs.technion.ac.il>
      Reviewed-by: NRadim Krčmář <rkrcmar@redhat.com>
      Reviewed-by: NWanpeng Li <wanpeng.li@linux.intel.com>
      [As per Radim's review, use unsigned int for X2APIC_BROADCAST, return bool from
       kvm_apic_broadcast. - Paolo]
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      394457a9
  14. 24 10月, 2014 2 次提交
    • A
      KVM: x86: Prevent host from panicking on shared MSR writes. · 8b3c3104
      Andy Honig 提交于
      The previous patch blocked invalid writes directly when the MSR
      is written.  As a precaution, prevent future similar mistakes by
      gracefulling handle GPs caused by writes to shared MSRs.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NAndrew Honig <ahonig@google.com>
      [Remove parts obsoleted by Nadav's patch. - Paolo]
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      8b3c3104
    • N
      KVM: x86: Check non-canonical addresses upon WRMSR · 854e8bb1
      Nadav Amit 提交于
      Upon WRMSR, the CPU should inject #GP if a non-canonical value (address) is
      written to certain MSRs. The behavior is "almost" identical for AMD and Intel
      (ignoring MSRs that are not implemented in either architecture since they would
      anyhow #GP). However, IA32_SYSENTER_ESP and IA32_SYSENTER_EIP cause #GP if
      non-canonical address is written on Intel but not on AMD (which ignores the top
      32-bits).
      
      Accordingly, this patch injects a #GP on the MSRs which behave identically on
      Intel and AMD.  To eliminate the differences between the architecutres, the
      value which is written to IA32_SYSENTER_ESP and IA32_SYSENTER_EIP is turned to
      canonical value before writing instead of injecting a #GP.
      
      Some references from Intel and AMD manuals:
      
      According to Intel SDM description of WRMSR instruction #GP is expected on
      WRMSR "If the source register contains a non-canonical address and ECX
      specifies one of the following MSRs: IA32_DS_AREA, IA32_FS_BASE, IA32_GS_BASE,
      IA32_KERNEL_GS_BASE, IA32_LSTAR, IA32_SYSENTER_EIP, IA32_SYSENTER_ESP."
      
      According to AMD manual instruction manual:
      LSTAR/CSTAR (SYSCALL): "The WRMSR instruction loads the target RIP into the
      LSTAR and CSTAR registers.  If an RIP written by WRMSR is not in canonical
      form, a general-protection exception (#GP) occurs."
      IA32_GS_BASE and IA32_FS_BASE (WRFSBASE/WRGSBASE): "The address written to the
      base field must be in canonical form or a #GP fault will occur."
      IA32_KERNEL_GS_BASE (SWAPGS): "The address stored in the KernelGSbase MSR must
      be in canonical form."
      
      This patch fixes CVE-2014-3610.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NNadav Amit <namit@cs.technion.ac.il>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      854e8bb1
  15. 24 9月, 2014 5 次提交
  16. 17 9月, 2014 1 次提交
    • T
      kvm: Remove ept_identity_pagetable from struct kvm_arch. · a255d479
      Tang Chen 提交于
      kvm_arch->ept_identity_pagetable holds the ept identity pagetable page. But
      it is never used to refer to the page at all.
      
      In vcpu initialization, it indicates two things:
      1. indicates if ept page is allocated
      2. indicates if a memory slot for identity page is initialized
      
      Actually, kvm_arch->ept_identity_pagetable_done is enough to tell if the ept
      identity pagetable is initialized. So we can remove ept_identity_pagetable.
      
      NOTE: In the original code, ept identity pagetable page is pinned in memroy.
            As a result, it cannot be migrated/hot-removed. After this patch, since
            kvm_arch->ept_identity_pagetable is removed, ept identity pagetable page
            is no longer pinned in memory. And it can be migrated/hot-removed.
      Signed-off-by: NTang Chen <tangchen@cn.fujitsu.com>
      Reviewed-by: NGleb Natapov <gleb@kernel.org>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      a255d479
  17. 05 9月, 2014 2 次提交
  18. 03 9月, 2014 1 次提交
    • D
      kvm: x86: fix stale mmio cache bug · 56f17dd3
      David Matlack 提交于
      The following events can lead to an incorrect KVM_EXIT_MMIO bubbling
      up to userspace:
      
      (1) Guest accesses gpa X without a memory slot. The gfn is cached in
      struct kvm_vcpu_arch (mmio_gfn). On Intel EPT-enabled hosts, KVM sets
      the SPTE write-execute-noread so that future accesses cause
      EPT_MISCONFIGs.
      
      (2) Host userspace creates a memory slot via KVM_SET_USER_MEMORY_REGION
      covering the page just accessed.
      
      (3) Guest attempts to read or write to gpa X again. On Intel, this
      generates an EPT_MISCONFIG. The memory slot generation number that
      was incremented in (2) would normally take care of this but we fast
      path mmio faults through quickly_check_mmio_pf(), which only checks
      the per-vcpu mmio cache. Since we hit the cache, KVM passes a
      KVM_EXIT_MMIO up to userspace.
      
      This patch fixes the issue by using the memslot generation number
      to validate the mmio cache.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NDavid Matlack <dmatlack@google.com>
      [xiaoguangrong: adjust the code to make it simpler for stable-tree fix.]
      Signed-off-by: NXiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
      Reviewed-by: NDavid Matlack <dmatlack@google.com>
      Reviewed-by: NXiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
      Tested-by: NDavid Matlack <dmatlack@google.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      56f17dd3
  19. 29 8月, 2014 2 次提交
  20. 22 8月, 2014 1 次提交
  21. 19 8月, 2014 2 次提交
  22. 21 7月, 2014 1 次提交
    • N
      KVM: x86: DR6/7.RTM cannot be written · 6f43ed01
      Nadav Amit 提交于
      Haswell and newer Intel CPUs have support for RTM, and in that case DR6.RTM is
      not fixed to 1 and DR7.RTM is not fixed to zero. That is not the case in the
      current KVM implementation. This bug is apparent only if the MOV-DR instruction
      is emulated or the host also debugs the guest.
      
      This patch is a partial fix which enables DR6.RTM and DR7.RTM to be cleared and
      set respectively. It also sets DR6.RTM upon every debug exception. Obviously,
      it is not a complete fix, as debugging of RTM is still unsupported.
      Signed-off-by: NNadav Amit <namit@cs.technion.ac.il>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      6f43ed01
  23. 11 7月, 2014 1 次提交
    • P
      KVM: x86: return all bits from get_interrupt_shadow · 37ccdcbe
      Paolo Bonzini 提交于
      For the next patch we will need to know the full state of the
      interrupt shadow; we will then set KVM_REQ_EVENT when one bit
      is cleared.
      
      However, right now get_interrupt_shadow only returns the one
      corresponding to the emulated instruction, or an unconditional
      0 if the emulated instruction does not have an interrupt shadow.
      This is confusing and does not allow us to check for cleared
      bits as mentioned above.
      
      Clean the callback up, and modify toggle_interruptibility to
      match the comment above the call.  As a small result, the
      call to set_interrupt_shadow will be skipped in the common
      case where int_shadow == 0 && mask == 0.
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      37ccdcbe