1. 01 Aug, 2016 5 commits
    • James Hogan's avatar
      MIPS: KVM: Use virt_to_phys() to get commpage PFN · cfacaced
      James Hogan authored
      Calculate the PFN of the commpage using virt_to_phys() instead of
      CPHYSADDR(). This is more portable as kzalloc() may allocate from XKPhys
      instead of KSeg0 on 64-bit kernels, which CPHYSADDR() doesn't handle.
      This is sufficient for highmem kernels too since kzalloc() will allocate
      from lowmem in KSeg0.
      Signed-off-by: default avatarJames Hogan <james.hogan@imgtec.com>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: "Radim Krčmář" <rkrcmar@redhat.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: linux-mips@linux-mips.org
      Cc: kvm@vger.kernel.org
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      cfacaced
    • James Hogan's avatar
      MIPS: Fix definition of KSEGX() for 64-bit · 6002bdd3
      James Hogan authored
      The KSEGX() macro is defined to 32-bit sign extend the address argument
      and logically AND the result with 0xe0000000, with the final result
      usually compared against one of the CKSEG macros. However the literal
      0xe0000000 is unsigned as the high bit is set, and is therefore
      zero-extended on 64-bit kernels, resulting in the sign extension bits of
      the argument being masked to zero. This results in the odd situation
      where:
      
        KSEGX(CKSEG) != CKSEG
        (0xffffffff80000000 & 0x00000000e0000000) != 0xffffffff80000000)
      
      Fix this by 32-bit sign extending the 0xe0000000 literal using
      _ACAST32_.
      
      This will help some MIPS KVM code handling 32-bit guest addresses to
      work on 64-bit host kernels, but will also affect KSEGX in
      dec_kn01_be_backend() on a 64-bit DECstation kernel, and the SiByte DMA
      page ops KSEGX check in clear_page() and copy_page() on 64-bit SB1
      kernels, neither of which appear to be designed with 64-bit segments in
      mind anyway.
      Signed-off-by: default avatarJames Hogan <james.hogan@imgtec.com>
      Acked-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Cc: Maciej W. Rozycki <macro@linux-mips.org>
      Cc: linux-mips@linux-mips.org
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      6002bdd3
    • Jim Mattson's avatar
      KVM: VMX: Add VMCS to CPU's loaded VMCSs before VMPTRLD · b80c76ec
      Jim Mattson authored
      Kexec needs to know the addresses of all VMCSs that are active on
      each CPU, so that it can flush them from the VMCS caches. It is
      safe to record superfluous addresses that are not associated with
      an active VMCS, but it is not safe to omit an address associated
      with an active VMCS.
      
      After a call to vmcs_load, the VMCS that was loaded is active on
      the CPU. The VMCS should be added to the CPU's list of active
      VMCSs before it is loaded.
      Signed-off-by: default avatarJim Mattson <jmattson@google.com>
      Signed-off-by: default avatarRadim Krčmář <rkrcmar@redhat.com>
      b80c76ec
    • David Matlack's avatar
      kvm: x86: nVMX: maintain internal copy of current VMCS · 4f2777bc
      David Matlack authored
      KVM maintains L1's current VMCS in guest memory, at the guest physical
      page identified by the argument to VMPTRLD. This makes hairy
      time-of-check to time-of-use bugs possible,as VCPUs can be writing
      the the VMCS page in memory while KVM is emulating VMLAUNCH and
      VMRESUME.
      
      The spec documents that writing to the VMCS page while it is loaded is
      "undefined". Therefore it is reasonable to load the entire VMCS into
      an internal cache during VMPTRLD and ignore writes to the VMCS page
      -- the guest should be using VMREAD and VMWRITE to access the current
      VMCS.
      
      To adhere to the spec, KVM should flush the current VMCS during VMPTRLD,
      and the target VMCS during VMCLEAR (as given by the operand to VMCLEAR).
      Since this implementation of VMCS caching only maintains the the current
      VMCS, VMCLEAR will only do a flush if the operand to VMCLEAR is the
      current VMCS pointer.
      
      KVM will also flush during VMXOFF, which is not mandated by the spec,
      but also not in conflict with the spec.
      Signed-off-by: default avatarDavid Matlack <dmatlack@google.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      4f2777bc
    • Radim Krčmář's avatar
      Merge branch 'kvm-ppc-next' of... · 601045bf
      Radim Krčmář authored
      Merge branch 'kvm-ppc-next' of git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc into next
      
      Fix for CVE-2016-5412, a denial-of-service vulnerability in HV KVM on
      POWER8 machines
      601045bf
  2. 28 Jul, 2016 2 commits
    • Paul Mackerras's avatar
      KVM: PPC: Book3S HV: Save/restore TM state in H_CEDE · 93d17397
      Paul Mackerras authored
      It turns out that if the guest does a H_CEDE while the CPU is in
      a transactional state, and the H_CEDE does a nap, and the nap
      loses the architected state of the CPU (which is is allowed to do),
      then we lose the checkpointed state of the virtual CPU.  In addition,
      the transactional-memory state recorded in the MSR gets reset back
      to non-transactional, and when we try to return to the guest, we take
      a TM bad thing type of program interrupt because we are trying to
      transition from non-transactional to transactional with a hrfid
      instruction, which is not permitted.
      
      The result of the program interrupt occurring at that point is that
      the host CPU will hang in an infinite loop with interrupts disabled.
      Thus this is a denial of service vulnerability in the host which can
      be triggered by any guest (and depending on the guest kernel, it can
      potentially triggered by unprivileged userspace in the guest).
      
      This vulnerability has been assigned the ID CVE-2016-5412.
      
      To fix this, we save the TM state before napping and restore it
      on exit from the nap, when handling a H_CEDE in real mode.  The
      case where H_CEDE exits to host virtual mode is already OK (as are
      other hcalls which exit to host virtual mode) because the exit
      path saves the TM state.
      
      Cc: stable@vger.kernel.org # v3.15+
      Signed-off-by: default avatarPaul Mackerras <paulus@ozlabs.org>
      93d17397
    • Paul Mackerras's avatar
      KVM: PPC: Book3S HV: Pull out TM state save/restore into separate procedures · f024ee09
      Paul Mackerras authored
      This moves the transactional memory state save and restore sequences
      out of the guest entry/exit paths into separate procedures.  This is
      so that these sequences can be used in going into and out of nap
      in a subsequent patch.
      
      The only code changes here are (a) saving and restore LR on the
      stack, since these new procedures get called with a bl instruction,
      (b) explicitly saving r1 into the PACA instead of assuming that
      HSTATE_HOST_R1(r13) is already set, and (c) removing an unnecessary
      and redundant setting of MSR[TM] that should have been removed by
      commit 9d4d0bdd9e0a ("KVM: PPC: Book3S HV: Add transactional memory
      support", 2013-09-24) but wasn't.
      
      Cc: stable@vger.kernel.org # v3.15+
      Signed-off-by: default avatarPaul Mackerras <paulus@ozlabs.org>
      f024ee09
  3. 22 Jul, 2016 1 commit
  4. 21 Jul, 2016 1 commit
  5. 18 Jul, 2016 31 commits