1. 10 Oct, 2018 2 commits
    • Juergen Gross's avatar
      x86/boot: Add ACPI RSDP address to setup_header · ae7e1238
      Juergen Gross authored
      Xen PVH guests receive the address of the RSDP table from Xen. In order
      to support booting a Xen PVH guest via Grub2 using the standard x86
      boot entry we need a way for Grub2 to pass the RSDP address to the
      kernel.
      
      For this purpose expand the struct setup_header to hold the physical
      address of the RSDP address. Being zero means it isn't specified and
      has to be located the legacy way (searching through low memory or
      EBDA).
      
      While documenting the new setup_header layout and protocol version
      2.14 add the missing documentation of protocol version 2.13.
      
      There are Grub2 versions in several distros with a downstream patch
      violating the boot protocol by writing past the end of setup_header.
      This requires another update of the boot protocol to enable the kernel
      to distinguish between a specified RSDP address and one filled with
      garbage by such a broken Grub2.
      
      From protocol 2.14 on Grub2 will write the version it is supporting
      (but never a higher value than found to be supported by the kernel)
      ored with 0x8000 to the version field of setup_header. This enables
      the kernel to know up to which field Grub2 has written information
      to. All fields after that are supposed to be clobbered.
      Signed-off-by: default avatarJuergen Gross <jgross@suse.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: boris.ostrovsky@oracle.com
      Cc: bp@alien8.de
      Cc: corbet@lwn.net
      Cc: linux-doc@vger.kernel.org
      Cc: xen-devel@lists.xenproject.org
      Link: http://lkml.kernel.org/r/20181010061456.22238-3-jgross@suse.comSigned-off-by: Ingo Molnar's avatarIngo Molnar <mingo@kernel.org>
      ae7e1238
    • Juergen Gross's avatar
      x86/xen: Fix boot loader version reported for PVH guests · 357d291c
      Juergen Gross authored
      The boot loader version reported via sysfs is wrong in case of the
      kernel being booted via the Xen PVH boot entry. it should be 2.12
      (0x020c), but it is reported to be 2.18 (0x0212).
      
      As the current way to set the version is error prone use the more
      readable variant (2 << 8) | 12.
      Signed-off-by: default avatarJuergen Gross <jgross@suse.com>
      Cc: <stable@vger.kernel.org> # 4.12
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: boris.ostrovsky@oracle.com
      Cc: bp@alien8.de
      Cc: corbet@lwn.net
      Cc: linux-doc@vger.kernel.org
      Cc: xen-devel@lists.xenproject.org
      Link: http://lkml.kernel.org/r/20181010061456.22238-2-jgross@suse.comSigned-off-by: Ingo Molnar's avatarIngo Molnar <mingo@kernel.org>
      357d291c
  2. 04 Oct, 2018 4 commits
  3. 03 Oct, 2018 2 commits
  4. 02 Oct, 2018 6 commits
  5. 01 Oct, 2018 4 commits
    • Sean Christopherson's avatar
      KVM: x86: fix L1TF's MMIO GFN calculation · daa07cbc
      Sean Christopherson authored
      One defense against L1TF in KVM is to always set the upper five bits
      of the *legal* physical address in the SPTEs for non-present and
      reserved SPTEs, e.g. MMIO SPTEs.  In the MMIO case, the GFN of the
      MMIO SPTE may overlap with the upper five bits that are being usurped
      to defend against L1TF.  To preserve the GFN, the bits of the GFN that
      overlap with the repurposed bits are shifted left into the reserved
      bits, i.e. the GFN in the SPTE will be split into high and low parts.
      When retrieving the GFN from the MMIO SPTE, e.g. to check for an MMIO
      access, get_mmio_spte_gfn() unshifts the affected bits and restores
      the original GFN for comparison.  Unfortunately, get_mmio_spte_gfn()
      neglects to mask off the reserved bits in the SPTE that were used to
      store the upper chunk of the GFN.  As a result, KVM fails to detect
      MMIO accesses whose GPA overlaps the repurprosed bits, which in turn
      causes guest panics and hangs.
      
      Fix the bug by generating a mask that covers the lower chunk of the
      GFN, i.e. the bits that aren't shifted by the L1TF mitigation.  The
      alternative approach would be to explicitly zero the five reserved
      bits that are used to store the upper chunk of the GFN, but that
      requires additional run-time computation and makes an already-ugly
      bit of code even more inscrutable.
      
      I considered adding a WARN_ON_ONCE(low_phys_bits-1 <= PAGE_SHIFT) to
      warn if GENMASK_ULL() generated a nonsensical value, but that seemed
      silly since that would mean a system that supports VMX has less than
      18 bits of physical address space...
      Reported-by: default avatarSakari Ailus <sakari.ailus@iki.fi>
      Fixes: d9b47449c1a1 ("kvm: x86: Set highest physical address bits in non-present/reserved SPTEs")
      Cc: Junaid Shahid <junaids@google.com>
      Cc: Jim Mattson <jmattson@google.com>
      Cc: stable@vger.kernel.org
      Reviewed-by: default avatarJunaid Shahid <junaids@google.com>
      Tested-by: default avatarSakari Ailus <sakari.ailus@linux.intel.com>
      Signed-off-by: default avatarSean Christopherson <sean.j.christopherson@intel.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      daa07cbc
    • Liran Alon's avatar
      KVM: nVMX: Fix emulation of VM_ENTRY_LOAD_BNDCFGS · 62cf9bd8
      Liran Alon authored
      L2 IA32_BNDCFGS should be updated with vmcs12->guest_bndcfgs only
      when VM_ENTRY_LOAD_BNDCFGS is specified in vmcs12->vm_entry_controls.
      
      Otherwise, L2 IA32_BNDCFGS should be set to vmcs01->guest_bndcfgs which
      is L1 IA32_BNDCFGS.
      Reviewed-by: default avatarNikita Leshchenko <nikita.leshchenko@oracle.com>
      Reviewed-by: default avatarDarren Kenny <darren.kenny@oracle.com>
      Signed-off-by: default avatarLiran Alon <liran.alon@oracle.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      62cf9bd8
    • Liran Alon's avatar
      KVM: x86: Do not use kvm_x86_ops->mpx_supported() directly · 503234b3
      Liran Alon authored
      Commit a87036ad ("KVM: x86: disable MPX if host did not enable
      MPX XSAVE features") introduced kvm_mpx_supported() to return true
      iff MPX is enabled in the host.
      
      However, that commit seems to have missed replacing some calls to
      kvm_x86_ops->mpx_supported() to kvm_mpx_supported().
      
      Complete original commit by replacing remaining calls to
      kvm_mpx_supported().
      
      Fixes: a87036ad ("KVM: x86: disable MPX if host did not enable
      MPX XSAVE features")
      Suggested-by: default avatarSean Christopherson <sean.j.christopherson@intel.com>
      Signed-off-by: default avatarLiran Alon <liran.alon@oracle.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      503234b3
    • Liran Alon's avatar
      KVM: nVMX: Do not expose MPX VMX controls when guest MPX disabled · 5f76f6f5
      Liran Alon authored
      Before this commit, KVM exposes MPX VMX controls to L1 guest only based
      on if KVM and host processor supports MPX virtualization.
      However, these controls should be exposed to guest only in case guest
      vCPU supports MPX.
      
      Without this change, a L1 guest running with kernel which don't have
      commit 691bd434 ("kvm: vmx: allow host to access guest
      MSR_IA32_BNDCFGS") asserts in QEMU on the following:
      	qemu-kvm: error: failed to set MSR 0xd90 to 0x0
      	qemu-kvm: .../qemu-2.10.0/target/i386/kvm.c:1801 kvm_put_msrs:
      	Assertion 'ret == cpu->kvm_msr_buf->nmsrs failed'
      This is because L1 KVM kvm_init_msr_list() will see that
      vmx_mpx_supported() (As it only checks MPX VMX controls support) and
      therefore KVM_GET_MSR_INDEX_LIST IOCTL will include MSR_IA32_BNDCFGS.
      However, later when L1 will attempt to set this MSR via KVM_SET_MSRS
      IOCTL, it will fail because !guest_cpuid_has_mpx(vcpu).
      
      Therefore, fix the issue by exposing MPX VMX controls to L1 guest only
      when vCPU supports MPX.
      
      Fixes: 36be0b9d ("KVM: x86: Add nested virtualization support for MPX")
      Reported-by: default avatarEyal Moscovici <eyal.moscovici@oracle.com>
      Reviewed-by: default avatarNikita Leshchenko <nikita.leshchenko@oracle.com>
      Reviewed-by: default avatarDarren Kenny <darren.kenny@oracle.com>
      Signed-off-by: default avatarLiran Alon <liran.alon@oracle.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      5f76f6f5
  6. 27 Sep, 2018 1 commit
    • Kairui Song's avatar
      x86/boot: Fix kexec booting failure in the SEV bit detection code · bdec8d7f
      Kairui Song authored
      Commit
      
        1958b5fc ("x86/boot: Add early boot support when running with SEV active")
      
      can occasionally cause system resets when kexec-ing a second kernel even
      if SEV is not active.
      
      That's because get_sev_encryption_bit() uses 32-bit rIP-relative
      addressing to read the value of enc_bit - a variable which caches a
      previously detected encryption bit position - but kexec may allocate
      the early boot code to a higher location, beyond the 32-bit addressing
      limit.
      
      In this case, garbage will be read and get_sev_encryption_bit() will
      return the wrong value, leading to accessing memory with the wrong
      encryption setting.
      
      Therefore, remove enc_bit, and thus get rid of the need to do 32-bit
      rIP-relative addressing in the first place.
      
       [ bp: massage commit message heavily. ]
      
      Fixes: 1958b5fc ("x86/boot: Add early boot support when running with SEV active")
      Suggested-by: default avatarBorislav Petkov <bp@suse.de>
      Signed-off-by: default avatarKairui Song <kasong@redhat.com>
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Reviewed-by: default avatarTom Lendacky <thomas.lendacky@amd.com>
      Cc: linux-kernel@vger.kernel.org
      Cc: tglx@linutronix.de
      Cc: mingo@redhat.com
      Cc: hpa@zytor.com
      Cc: brijesh.singh@amd.com
      Cc: kexec@lists.infradead.org
      Cc: dyoung@redhat.com
      Cc: bhe@redhat.com
      Cc: ghook@redhat.com
      Link: https://lkml.kernel.org/r/20180927123845.32052-1-kasong@redhat.com
      bdec8d7f
  7. 24 Sep, 2018 1 commit
    • Paolo Bonzini's avatar
      KVM: x86: never trap MSR_KERNEL_GS_BASE · 4679b61f
      Paolo Bonzini authored
      KVM has an old optimization whereby accesses to the kernel GS base MSR
      are trapped when the guest is in 32-bit and not when it is in 64-bit mode.
      The idea is that swapgs is not available in 32-bit mode, thus the
      guest has no reason to access the MSR unless in 64-bit mode and
      32-bit applications need not pay the price of switching the kernel GS
      base between the host and the guest values.
      
      However, this optimization adds complexity to the code for little
      benefit (these days most guests are going to be 64-bit anyway) and in fact
      broke after commit 678e315e ("KVM: vmx: add dedicated utility to
      access guest's kernel_gs_base", 2018-08-06); the guest kernel GS base
      can be corrupted across SMIs and UEFI Secure Boot is therefore broken
      (a secure boot Linux guest, for example, fails to reach the login prompt
      about half the time).  This patch just removes the optimization; the
      kernel GS base MSR is now never trapped by KVM, similarly to the FS and
      GS base MSRs.
      
      Fixes: 678e315eReviewed-by: default avatarSean Christopherson <sean.j.christopherson@intel.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      4679b61f
  8. 20 Sep, 2018 2 commits
  9. 19 Sep, 2018 18 commits