1. 13 Feb, 2018 6 commits
    • Ingo Molnar's avatar
      x86/speculation: Clean up various Spectre related details · 21e433bd
      Ingo Molnar authored
      Harmonize all the Spectre messages so that a:
      
          dmesg | grep -i spectre
      
      ... gives us most Spectre related kernel boot messages.
      
      Also fix a few other details:
      
       - clarify a comment about firmware speculation control
      
       - s/KPTI/PTI
      
       - remove various line-breaks that made the code uglier
      Acked-by: default avatarDavid Woodhouse <dwmw@amazon.co.uk>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Arjan van de Ven <arjan@linux.intel.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: David Woodhouse <dwmw2@infradead.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      21e433bd
    • KarimAllah Ahmed's avatar
      KVM/nVMX: Set the CPU_BASED_USE_MSR_BITMAPS if we have a valid L02 MSR bitmap · 3712caeb
      KarimAllah Ahmed authored
      We either clear the CPU_BASED_USE_MSR_BITMAPS and end up intercepting all
      MSR accesses or create a valid L02 MSR bitmap and use that. This decision
      has to be made every time we evaluate whether we are going to generate the
      L02 MSR bitmap.
      
      Before commit:
      
        d28b387f ("KVM/VMX: Allow direct access to MSR_IA32_SPEC_CTRL")
      
      ... this was probably OK since the decision was always identical.
      
      This is no longer the case now since the MSR bitmap might actually
      change once we decide to not intercept SPEC_CTRL and PRED_CMD.
      Signed-off-by: default avatarKarimAllah Ahmed <karahmed@amazon.de>
      Signed-off-by: default avatarDavid Woodhouse <dwmw@amazon.co.uk>
      Acked-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Arjan van de Ven <arjan@linux.intel.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: David Woodhouse <dwmw2@infradead.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Josh Poimboeuf <jpoimboe@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: arjan.van.de.ven@intel.com
      Cc: dave.hansen@intel.com
      Cc: jmattson@google.com
      Cc: kvm@vger.kernel.org
      Cc: sironi@amazon.de
      Link: http://lkml.kernel.org/r/1518305967-31356-6-git-send-email-dwmw@amazon.co.ukSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      3712caeb
    • KarimAllah Ahmed's avatar
      X86/nVMX: Properly set spec_ctrl and pred_cmd before merging MSRs · 206587a9
      KarimAllah Ahmed authored
      These two variables should check whether SPEC_CTRL and PRED_CMD are
      supposed to be passed through to L2 guests or not. While
      msr_write_intercepted_l01 would return 'true' if it is not passed through.
      
      So just invert the result of msr_write_intercepted_l01 to implement the
      correct semantics.
      Signed-off-by: default avatarKarimAllah Ahmed <karahmed@amazon.de>
      Signed-off-by: default avatarDavid Woodhouse <dwmw@amazon.co.uk>
      Reviewed-by: default avatarJim Mattson <jmattson@google.com>
      Acked-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Arjan van de Ven <arjan@linux.intel.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: David Woodhouse <dwmw2@infradead.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Josh Poimboeuf <jpoimboe@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: arjan.van.de.ven@intel.com
      Cc: dave.hansen@intel.com
      Cc: kvm@vger.kernel.org
      Cc: sironi@amazon.de
      Fixes: 086e7d4118cc ("KVM: VMX: Allow direct access to MSR_IA32_SPEC_CTRL")
      Link: http://lkml.kernel.org/r/1518305967-31356-5-git-send-email-dwmw@amazon.co.ukSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      206587a9
    • David Woodhouse's avatar
      KVM/x86: Reduce retpoline performance impact in slot_handle_level_range(), by... · 928a4c39
      David Woodhouse authored
      KVM/x86: Reduce retpoline performance impact in slot_handle_level_range(), by always inlining iterator helper methods
      
      With retpoline, tight loops of "call this function for every XXX" are
      very much pessimised by taking a prediction miss *every* time. This one
      is by far the biggest contributor to the guest launch time with retpoline.
      
      By marking the iterator slot_handle_…() functions always_inline, we can
      ensure that the indirect function call can be optimised away into a
      direct call and it actually generates slightly smaller code because
      some of the other conditionals can get optimised away too.
      
      Performance is now pretty close to what we see with nospectre_v2 on
      the command line.
      Suggested-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Tested-by: default avatarFilippo Sironi <sironi@amazon.de>
      Signed-off-by: default avatarDavid Woodhouse <dwmw@amazon.co.uk>
      Reviewed-by: default avatarFilippo Sironi <sironi@amazon.de>
      Acked-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Arjan van de Ven <arjan@linux.intel.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: David Woodhouse <dwmw2@infradead.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: arjan.van.de.ven@intel.com
      Cc: dave.hansen@intel.com
      Cc: jmattson@google.com
      Cc: karahmed@amazon.de
      Cc: kvm@vger.kernel.org
      Cc: rkrcmar@redhat.com
      Link: http://lkml.kernel.org/r/1518305967-31356-4-git-send-email-dwmw@amazon.co.ukSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      928a4c39
    • David Woodhouse's avatar
      Revert "x86/speculation: Simplify indirect_branch_prediction_barrier()" · f208820a
      David Woodhouse authored
      This reverts commit 64e16720.
      
      We cannot call C functions like that, without marking all the
      call-clobbered registers as, well, clobbered. We might have got away
      with it for now because the __ibp_barrier() function was *fairly*
      unlikely to actually use any other registers. But no. Just no.
      Signed-off-by: default avatarDavid Woodhouse <dwmw@amazon.co.uk>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Arjan van de Ven <arjan@linux.intel.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: David Woodhouse <dwmw2@infradead.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: arjan.van.de.ven@intel.com
      Cc: dave.hansen@intel.com
      Cc: jmattson@google.com
      Cc: karahmed@amazon.de
      Cc: kvm@vger.kernel.org
      Cc: pbonzini@redhat.com
      Cc: rkrcmar@redhat.com
      Cc: sironi@amazon.de
      Link: http://lkml.kernel.org/r/1518305967-31356-3-git-send-email-dwmw@amazon.co.ukSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      f208820a
    • David Woodhouse's avatar
      x86/speculation: Correct Speculation Control microcode blacklist again · d37fc6d3
      David Woodhouse authored
      Arjan points out that the Intel document only clears the 0xc2 microcode
      on *some* parts with CPUID 506E3 (INTEL_FAM6_SKYLAKE_DESKTOP stepping 3).
      For the Skylake H/S platform it's OK but for Skylake E3 which has the
      same CPUID it isn't (yet) cleared.
      
      So removing it from the blacklist was premature. Put it back for now.
      
      Also, Arjan assures me that the 0x84 microcode for Kaby Lake which was
      featured in one of the early revisions of the Intel document was never
      released to the public, and won't be until/unless it is also validated
      as safe. So those can change to 0x80 which is what all *other* versions
      of the doc have identified.
      
      Once the retrospective testing of existing public microcodes is done, we
      should be back into a mode where new microcodes are only released in
      batches and we shouldn't even need to update the blacklist for those
      anyway, so this tweaking of the list isn't expected to be a thing which
      keeps happening.
      Requested-by: default avatarArjan van de Ven <arjan.van.de.ven@intel.com>
      Signed-off-by: default avatarDavid Woodhouse <dwmw@amazon.co.uk>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Arjan van de Ven <arjan@linux.intel.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: David Woodhouse <dwmw2@infradead.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: arjan.van.de.ven@intel.com
      Cc: dave.hansen@intel.com
      Cc: kvm@vger.kernel.org
      Cc: pbonzini@redhat.com
      Link: http://lkml.kernel.org/r/1518449255-2182-1-git-send-email-dwmw@amazon.co.ukSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      d37fc6d3
  2. 11 Feb, 2018 1 commit
    • David Woodhouse's avatar
      x86/speculation: Update Speculation Control microcode blacklist · 17513420
      David Woodhouse authored
      Intel have retroactively blessed the 0xc2 microcode on Skylake mobile
      and desktop parts, and the Gemini Lake 0x22 microcode is apparently fine
      too. We blacklisted the latter purely because it was present with all
      the other problematic ones in the 2018-01-08 release, but now it's
      explicitly listed as OK.
      
      We still list 0x84 for the various Kaby Lake / Coffee Lake parts, as
      that appeared in one version of the blacklist and then reverted to
      0x80 again. We can change it if 0x84 is actually announced to be safe.
      Signed-off-by: default avatarDavid Woodhouse <dwmw@amazon.co.uk>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Arjan van de Ven <arjan@linux.intel.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: David Woodhouse <dwmw2@infradead.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: arjan.van.de.ven@intel.com
      Cc: jmattson@google.com
      Cc: karahmed@amazon.de
      Cc: kvm@vger.kernel.org
      Cc: pbonzini@redhat.com
      Cc: rkrcmar@redhat.com
      Cc: sironi@amazon.de
      Link: http://lkml.kernel.org/r/1518305967-31356-2-git-send-email-dwmw@amazon.co.ukSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      17513420
  3. 10 Feb, 2018 1 commit
    • Nadav Amit's avatar
      x86/mm/pti: Fix PTI comment in entry_SYSCALL_64() · 14b1fcc6
      Nadav Amit authored
      The comment is confusing since the path is taken when
      CONFIG_PAGE_TABLE_ISOLATION=y is disabled (while the comment says it is not
      taken).
      Signed-off-by: default avatarNadav Amit <namit@vmware.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Arjan van de Ven <arjan@linux.intel.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: David Woodhouse <dwmw2@infradead.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: nadav.amit@gmail.com
      Link: http://lkml.kernel.org/r/20180209170638.15161-1-namit@vmware.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      14b1fcc6
  4. 09 Feb, 2018 2 commits
  5. 06 Feb, 2018 3 commits
  6. 03 Feb, 2018 6 commits
  7. 02 Feb, 2018 4 commits
  8. 01 Feb, 2018 1 commit
  9. 31 Jan, 2018 2 commits
    • Paolo Bonzini's avatar
      KVM: VMX: make MSR bitmaps per-VCPU · 904e14fb
      Paolo Bonzini authored
      Place the MSR bitmap in struct loaded_vmcs, and update it in place
      every time the x2apic or APICv state can change.  This is rare and
      the loop can handle 64 MSRs per iteration, in a similar fashion as
      nested_vmx_prepare_msr_bitmap.
      
      This prepares for choosing, on a per-VM basis, whether to intercept
      the SPEC_CTRL and PRED_CMD MSRs.
      
      Cc: stable@vger.kernel.org       # prereq for Spectre mitigation
      Suggested-by: default avatarJim Mattson <jmattson@google.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      904e14fb
    • Josh Poimboeuf's avatar
      x86/paravirt: Remove 'noreplace-paravirt' cmdline option · 12c69f1e
      Josh Poimboeuf authored
      The 'noreplace-paravirt' option disables paravirt patching, leaving the
      original pv indirect calls in place.
      
      That's highly incompatible with retpolines, unless we want to uglify
      paravirt even further and convert the paravirt calls to retpolines.
      
      As far as I can tell, the option doesn't seem to be useful for much
      other than introducing surprising corner cases and making the kernel
      vulnerable to Spectre v2.  It was probably a debug option from the early
      paravirt days.  So just remove it.
      Signed-off-by: default avatarJosh Poimboeuf <jpoimboe@redhat.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Reviewed-by: default avatarJuergen Gross <jgross@suse.com>
      Cc: Andrea Arcangeli <aarcange@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Ashok Raj <ashok.raj@intel.com>
      Cc: Greg KH <gregkh@linuxfoundation.org>
      Cc: Jun Nakajima <jun.nakajima@intel.com>
      Cc: Tim Chen <tim.c.chen@linux.intel.com>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Dave Hansen <dave.hansen@intel.com>
      Cc: Asit Mallick <asit.k.mallick@intel.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Jason Baron <jbaron@akamai.com>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Alok Kataria <akataria@vmware.com>
      Cc: Arjan Van De Ven <arjan.van.de.ven@intel.com>
      Cc: David Woodhouse <dwmw2@infradead.org>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Link: https://lkml.kernel.org/r/20180131041333.2x6blhxirc2kclrq@treble
      12c69f1e
  10. 30 Jan, 2018 14 commits