1. 03 Feb, 2018 1 commit
  2. 25 Aug, 2017 1 commit
  3. 24 Aug, 2017 3 commits
  4. 08 Jun, 2017 1 commit
    • Wanpeng Li's avatar
      KVM: cpuid: Fix read/write out-of-bounds vulnerability in cpuid emulation · a3641631
      Wanpeng Li authored
      
      
      If "i" is the last element in the vcpu->arch.cpuid_entries[] array, it
      potentially can be exploited the vulnerability. this will out-of-bounds
      read and write.  Luckily, the effect is small:
      
      	/* when no next entry is found, the current entry[i] is reselected */
      	for (j = i + 1; ; j = (j + 1) % nent) {
      		struct kvm_cpuid_entry2 *ej = &vcpu->arch.cpuid_entries[j];
      		if (ej->function == e->function) {
      
      It reads ej->maxphyaddr, which is user controlled.  However...
      
      			ej->flags |= KVM_CPUID_FLAG_STATE_READ_NEXT;
      
      After cpuid_entries there is
      
      	int maxphyaddr;
      	struct x86_emulate_ctxt emulate_ctxt;  /* 16-byte aligned */
      
      So we have:
      
      - cpuid_entries at offset 1B50 (6992)
      - maxphyaddr at offset 27D0 (6992 + 3200 = 10192)
      - padding at 27D4...27DF
      - emulate_ctxt at 27E0
      
      And it writes in the padding.  Pfew, writing the ops field of emulate_ctxt
      would have been much worse.
      
      This patch fixes it by modding the index to avoid the out-of-bounds
      access. Worst case, i == j and ej->function == e->function,
      the loop can bail out.
      
      Reported-by: default avatarMoguofang <moguofang@huawei.com>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Radim Krčmář <rkrcmar@redhat.com>
      Cc: Guofang Mo <moguofang@huawei.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarWanpeng Li <wanpeng.li@hotmail.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      a3641631
  5. 21 Apr, 2017 1 commit
  6. 02 Mar, 2017 1 commit
  7. 17 Feb, 2017 1 commit
  8. 20 Jan, 2017 1 commit
  9. 17 Jan, 2017 1 commit
    • Piotr Luc's avatar
      kvm: x86: Expose Intel VPOPCNTDQ feature to guest · a17f3227
      Piotr Luc authored
      
      
      Vector population count instructions for dwords and qwords are to be
      used in future Intel Xeon & Xeon Phi processors. The bit 14 of
      CPUID[level:0x07, ECX] indicates that the new instructions are
      supported by a processor.
      
      The spec can be found in the Intel Software Developer Manual (SDM)
      or in the Instruction Set Extensions Programming Reference (ISE).
      
      Signed-off-by: default avatarPiotr Luc <piotr.luc@intel.com>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Radim Krčmář <rkrcmar@redhat.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: x86@kernel.org
      Cc: kvm@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarRadim Krčmář <rkrcmar@redhat.com>
      a17f3227
  10. 15 Dec, 2016 1 commit
  11. 08 Dec, 2016 2 commits
    • Kyle Huey's avatar
      KVM: x86: Add kvm_skip_emulated_instruction and use it. · 6affcbed
      Kyle Huey authored
      
      
      kvm_skip_emulated_instruction calls both
      kvm_x86_ops->skip_emulated_instruction and kvm_vcpu_check_singlestep,
      skipping the emulated instruction and generating a trap if necessary.
      
      Replacing skip_emulated_instruction calls with
      kvm_skip_emulated_instruction is straightforward, except for:
      
      - ICEBP, which is already inside a trap, so avoid triggering another trap.
      - Instructions that can trigger exits to userspace, such as the IO insns,
        MOVs to CR8, and HALT. If kvm_skip_emulated_instruction does trigger a
        KVM_GUESTDBG_SINGLESTEP exit, and the handling code for
        IN/OUT/MOV CR8/HALT also triggers an exit to userspace, the latter will
        take precedence. The singlestep will be triggered again on the next
        instruction, which is the current behavior.
      - Task switch instructions which would require additional handling (e.g.
        the task switch bit) and are instead left alone.
      - Cases where VMLAUNCH/VMRESUME do not proceed to the next instruction,
        which do not trigger singlestep traps as mentioned previously.
      
      Signed-off-by: default avatarKyle Huey <khuey@kylehuey.com>
      Signed-off-by: default avatarRadim Krčmář <rkrcmar@redhat.com>
      6affcbed
    • Kyle Huey's avatar
      KVM: x86: Add a return value to kvm_emulate_cpuid · 6a908b62
      Kyle Huey authored
      
      
      Once skipping the emulated instruction can potentially trigger an exit to
      userspace (via KVM_GUESTDBG_SINGLESTEP) kvm_emulate_cpuid will need to
      propagate a return value.
      
      Signed-off-by: default avatarKyle Huey <khuey@kylehuey.com>
      Signed-off-by: default avatarRadim Krčmář <rkrcmar@redhat.com>
      6a908b62
  12. 22 Nov, 2016 1 commit
  13. 16 Nov, 2016 2 commits
  14. 07 Oct, 2016 1 commit
  15. 19 Aug, 2016 1 commit
  16. 23 Jul, 2016 1 commit
    • Dan Williams's avatar
      Revert "KVM: x86: add pcommit support" · dfa169bb
      Dan Williams authored
      This reverts commit 8b3e34e4
      
      .
      
      Given the deprecation of the pcommit instruction, the relevant VMX
      features and CPUID bits are not going to be rolled into the SDM.  Remove
      their usage from KVM.
      
      Cc: Xiao Guangrong <guangrong.xiao@linux.intel.com>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      dfa169bb
  17. 14 Jul, 2016 1 commit
    • Paul Gortmaker's avatar
      x86/kvm: Audit and remove any unnecessary uses of module.h · 1767e931
      Paul Gortmaker authored
      
      
      Historically a lot of these existed because we did not have
      a distinction between what was modular code and what was providing
      support to modules via EXPORT_SYMBOL and friends.  That changed
      when we forked out support for the latter into the export.h file.
      
      This means we should be able to reduce the usage of module.h
      in code that is obj-y Makefile or bool Kconfig.  In the case of
      kvm where it is modular, we can extend that to also include files
      that are building basic support functionality but not related
      to loading or registering the final module; such files also have
      no need whatsoever for module.h
      
      The advantage in removing such instances is that module.h itself
      sources about 15 other headers; adding significantly to what we feed
      cpp, and it can obscure what headers we are effectively using.
      
      Since module.h was the source for init.h (for __init) and for
      export.h (for EXPORT_SYMBOL) we consider each instance for the
      presence of either and replace as needed.
      
      Several instances got replaced with moduleparam.h since that was
      really all that was required for those particular files.
      
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      Acked-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Radim Krčmář <rkrcmar@redhat.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: kvm@vger.kernel.org
      Link: http://lkml.kernel.org/r/20160714001901.31603-8-paul.gortmaker@windriver.com
      
      
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      1767e931
  18. 02 Jun, 2016 1 commit
  19. 13 Apr, 2016 1 commit
  20. 10 Apr, 2016 1 commit
  21. 22 Mar, 2016 2 commits
  22. 09 Mar, 2016 2 commits
  23. 01 Oct, 2015 2 commits
  24. 14 Sep, 2015 1 commit
    • Dave Hansen's avatar
      x86/fpu: Rename XSAVE macros · d91cab78
      Dave Hansen authored
      
      
      There are two concepts that have some confusing naming:
       1. Extended State Component numbers (currently called
          XFEATURE_BIT_*)
       2. Extended State Component masks (currently called XSTATE_*)
      
      The numbers are (currently) from 0-9.  State component 3 is the
      bounds registers for MPX, for instance.
      
      But when we want to enable "state component 3", we go set a bit
      in XCR0.  The bit we set is 1<<3.  We can check to see if a
      state component feature is enabled by looking at its bit.
      
      The current 'xfeature_bit's are at best xfeature bit _numbers_.
      Calling them bits is at best inconsistent with ending the enum
      list with 'XFEATURES_NR_MAX'.
      
      This patch renames the enum to be 'xfeature'.  These also
      happen to be what the Intel documentation calls a "state
      component".
      
      We also want to differentiate these from the "XSTATE_*" macros.
      The "XSTATE_*" macros are a mask, and we rename them to match.
      
      These macros are reasonably widely used so this patch is a
      wee bit big, but this really is just a rename.
      
      The only non-mechanical part of this is the
      
      	s/XSTATE_EXTEND_MASK/XFEATURE_MASK_EXTEND/
      
      We need a better name for it, but that's another patch.
      
      Signed-off-by: default avatarDave Hansen <dave.hansen@linux.intel.com>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      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>
      Cc: Tim Chen <tim.c.chen@linux.intel.com>
      Cc: dave@sr71.net
      Cc: linux-kernel@vger.kernel.org
      Link: http://lkml.kernel.org/r/20150902233126.38653250@viggo.jf.intel.com
      
      
      [ Ported to v4.3-rc1. ]
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      d91cab78
  25. 10 Jul, 2015 1 commit
    • Radim Krčmář's avatar
      KVM: VMX: fix vmwrite to invalid VMCS · 370777da
      Radim Krčmář authored
      fpu_activate is called outside of vcpu_load(), which means it should not
      touch VMCS, but fpu_activate needs to.  Avoid the call by moving it to a
      point where we know that the guest needs eager FPU and VMCS is loaded.
      
      This will get rid of the following trace
      
       vmwrite error: reg 6800 value 0 (err 1)
        [<ffffffff8162035b>] dump_stack+0x19/0x1b
        [<ffffffffa046c701>] vmwrite_error+0x2c/0x2e [kvm_intel]
        [<ffffffffa045f26f>] vmcs_writel+0x1f/0x30 [kvm_intel]
        [<ffffffffa04617e5>] vmx_fpu_activate.part.61+0x45/0xb0 [kvm_intel]
        [<ffffffffa0461865>] vmx_fpu_activate+0x15/0x20 [kvm_intel]
        [<ffffffffa0560b91>] kvm_arch_vcpu_create+0x51/0x70 [kvm]
        [<ffffffffa0548011>] kvm_vm_ioctl+0x1c1/0x760 [kvm]
        [<ffffffff8118b55a>] ? handle_mm_fault+0x49a/0xec0
        [<ffffffff811e47d5>] do_vfs_ioctl+0x2e5/0x4c0
        [<ffffffff8127abbe>] ? file_has_perm+0xae/0xc0
        [<ffffffff811e4a51>] SyS_ioctl+0xa1/0xc0
        [<ffffffff81630949>] system_call_fastpath+0x16/0x1b
      
      (Note: we also unconditionally activate FPU in vmx_vcpu_reset(), so the
       removed code added nothing.)
      
      Fixes: c447e76b
      
       ("kvm/fpu: Enable eager restore kvm FPU for MPX")
      Cc: <stable@vger.kernel.org>
      Reported-by: default avatarVlastimil Holer <vlastimil.holer@gmail.com>
      Signed-off-by: default avatarRadim Krčmář <rkrcmar@redhat.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      370777da
  26. 19 Jun, 2015 2 commits
  27. 28 May, 2015 1 commit
  28. 20 May, 2015 1 commit
  29. 19 May, 2015 2 commits
    • Ingo Molnar's avatar
      x86/fpu: Rename fpu/xsave.h to fpu/xstate.h · 669ebabb
      Ingo Molnar authored
      
      
      'xsave' is an x86 instruction name to most people - but xsave.h is
      about a lot more than just the XSAVE instruction: it includes
      definitions and support, both internal and external, related to
      xstate and xfeatures support.
      
      As a first step in cleaning up the various xstate uses rename this
      header to 'fpu/xstate.h' to better reflect what this header file
      is about.
      
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      669ebabb
    • Ingo Molnar's avatar
      x86/fpu: Move xsave.h to fpu/xsave.h · a137fb6b
      Ingo Molnar authored
      
      
      Move the xsave.h header file to the FPU directory as well.
      
      Reviewed-by: default avatarBorislav Petkov <bp@alien8.de>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      a137fb6b
  30. 08 Apr, 2015 1 commit
  31. 05 Dec, 2014 1 commit
    • Radim Krčmář's avatar
      KVM: cpuid: recompute CPUID 0xD.0:EBX,ECX · e08e8336
      Radim Krčmář authored
      
      
      We reused host EBX and ECX, but KVM might not support all features;
      emulated XSAVE size should be smaller.
      
      EBX depends on unknown XCR0, so we default to ECX.
      
      SDM CPUID (EAX = 0DH, ECX = 0):
       EBX Bits 31-00: Maximum size (bytes, from the beginning of the
           XSAVE/XRSTOR save area) required by enabled features in XCR0. May
           be different than ECX if some features at the end of the XSAVE save
           area are not enabled.
      
       ECX Bit 31-00: Maximum size (bytes, from the beginning of the
           XSAVE/XRSTOR save area) of the XSAVE/XRSTOR save area required by
           all supported features in the processor, i.e all the valid bit
           fields in XCR0.
      
      Signed-off-by: default avatarRadim Krčmář <rkrcmar@redhat.com>
      Tested-by: default avatarWanpeng Li <wanpeng.li@linux.intel.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      e08e8336