1. 30 Jan, 2018 3 commits
    • Josh Poimboeuf's avatar
      objtool: Add support for alternatives at the end of a section · 17bc3391
      Josh Poimboeuf authored
      Now that the previous patch gave objtool the ability to read retpoline
      alternatives, it shows a new warning:
      
        arch/x86/entry/entry_64.o: warning: objtool: .entry_trampoline: don't know how to handle alternatives at end of section
      
      This is due to the JMP_NOSPEC in entry_SYSCALL_64_trampoline().
      
      Previously, objtool ignored this situation because it wasn't needed, and
      it would have required a bit of extra code.  Now that this case exists,
      add proper support for it.
      Signed-off-by: default avatarJosh Poimboeuf <jpoimboe@redhat.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: David Woodhouse <dwmw2@infradead.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Guenter Roeck <linux@roeck-us.net>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/2a30a3c2158af47d891a76e69bb1ef347e0443fd.1517284349.git.jpoimboe@redhat.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      17bc3391
    • Josh Poimboeuf's avatar
      objtool: Improve retpoline alternative handling · a845c7cf
      Josh Poimboeuf authored
      Currently objtool requires all retpolines to be:
      
        a) patched in with alternatives; and
      
        b) annotated with ANNOTATE_NOSPEC_ALTERNATIVE.
      
      If you forget to do both of the above, objtool segfaults trying to
      dereference a NULL 'insn->call_dest' pointer.
      
      Avoid that situation and print a more helpful error message:
      
        quirks.o: warning: objtool: efi_delete_dummy_variable()+0x99: unsupported intra-function call
        quirks.o: warning: objtool: If this is a retpoline, please patch it in with alternatives and annotate it with ANNOTATE_NOSPEC_ALTERNATIVE.
      
      Future improvements can be made to make objtool smarter with respect to
      retpolines, but this is a good incremental improvement for now.
      Reported-and-tested-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarJosh Poimboeuf <jpoimboe@redhat.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: David Woodhouse <dwmw2@infradead.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/819e50b6d9c2e1a22e34c1a636c0b2057cc8c6e5.1517284349.git.jpoimboe@redhat.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      a845c7cf
    • Ingo Molnar's avatar
      Merge tag 'v4.15' into x86/pti, to be able to merge dependent changes · 7e86548e
      Ingo Molnar authored
      Time has come to switch PTI development over to a v4.15 base - we'll still
      try to make sure that all PTI fixes backport cleanly to v4.14 and earlier.
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      7e86548e
  2. 28 Jan, 2018 8 commits
  3. 27 Jan, 2018 6 commits
    • Borislav Petkov's avatar
      x86/speculation: Simplify indirect_branch_prediction_barrier() · 64e16720
      Borislav Petkov authored
      Make it all a function which does the WRMSR instead of having a hairy
      inline asm.
      
      [dwmw2: export it, fix CONFIG_RETPOLINE issues]
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Signed-off-by: default avatarDavid Woodhouse <dwmw@amazon.co.uk>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: ak@linux.intel.com
      Cc: dave.hansen@intel.com
      Cc: karahmed@amazon.de
      Cc: arjan@linux.intel.com
      Cc: torvalds@linux-foundation.org
      Cc: peterz@infradead.org
      Cc: bp@alien8.de
      Cc: pbonzini@redhat.com
      Cc: tim.c.chen@linux.intel.com
      Cc: gregkh@linux-foundation.org
      Link: https://lkml.kernel.org/r/1517070274-12128-4-git-send-email-dwmw@amazon.co.uk
      64e16720
    • Borislav Petkov's avatar
      x86/retpoline: Simplify vmexit_fill_RSB() · 1dde7415
      Borislav Petkov authored
      Simplify it to call an asm-function instead of pasting 41 insn bytes at
      every call site. Also, add alignment to the macro as suggested here:
      
        https://support.google.com/faqs/answer/7625886
      
      [dwmw2: Clean up comments, let it clobber %ebx and just tell the compiler]
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Signed-off-by: default avatarDavid Woodhouse <dwmw@amazon.co.uk>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: ak@linux.intel.com
      Cc: dave.hansen@intel.com
      Cc: karahmed@amazon.de
      Cc: arjan@linux.intel.com
      Cc: torvalds@linux-foundation.org
      Cc: peterz@infradead.org
      Cc: bp@alien8.de
      Cc: pbonzini@redhat.com
      Cc: tim.c.chen@linux.intel.com
      Cc: gregkh@linux-foundation.org
      Link: https://lkml.kernel.org/r/1517070274-12128-3-git-send-email-dwmw@amazon.co.uk
      1dde7415
    • David Woodhouse's avatar
      x86/cpufeatures: Clean up Spectre v2 related CPUID flags · 2961298e
      David Woodhouse authored
      We want to expose the hardware features simply in /proc/cpuinfo as "ibrs",
      "ibpb" and "stibp". Since AMD has separate CPUID bits for those, use them
      as the user-visible bits.
      
      When the Intel SPEC_CTRL bit is set which indicates both IBRS and IBPB
      capability, set those (AMD) bits accordingly. Likewise if the Intel STIBP
      bit is set, set the AMD STIBP that's used for the generic hardware
      capability.
      
      Hide the rest from /proc/cpuinfo by putting "" in the comments. Including
      RETPOLINE and RETPOLINE_AMD which shouldn't be visible there. There are
      patches to make the sysfs vulnerabilities information non-readable by
      non-root, and the same should apply to all information about which
      mitigations are actually in use. Those *shouldn't* appear in /proc/cpuinfo.
      
      The feature bit for whether IBPB is actually used, which is needed for
      ALTERNATIVEs, is renamed to X86_FEATURE_USE_IBPB.
      Originally-by: default avatarBorislav Petkov <bp@suse.de>
      Signed-off-by: default avatarDavid Woodhouse <dwmw@amazon.co.uk>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: ak@linux.intel.com
      Cc: dave.hansen@intel.com
      Cc: karahmed@amazon.de
      Cc: arjan@linux.intel.com
      Cc: torvalds@linux-foundation.org
      Cc: peterz@infradead.org
      Cc: bp@alien8.de
      Cc: pbonzini@redhat.com
      Cc: tim.c.chen@linux.intel.com
      Cc: gregkh@linux-foundation.org
      Link: https://lkml.kernel.org/r/1517070274-12128-2-git-send-email-dwmw@amazon.co.uk
      2961298e
    • Thomas Gleixner's avatar
      x86/cpu/bugs: Make retpoline module warning conditional · e383095c
      Thomas Gleixner authored
      If sysfs is disabled and RETPOLINE not defined:
      
      arch/x86/kernel/cpu/bugs.c:97:13: warning: ‘spectre_v2_bad_module’ defined but not used
      [-Wunused-variable]
       static bool spectre_v2_bad_module;
      
      Hide it.
      
      Fixes: caf7501a ("module/retpoline: Warn about missing retpoline in module")
      Reported-by: default avatarBorislav Petkov <bp@alien8.de>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: David Woodhouse <dwmw2@infradead.org>
      e383095c
    • Thomas Gleixner's avatar
      hrtimer: Reset hrtimer cpu base proper on CPU hotplug · d5421ea4
      Thomas Gleixner authored
      The hrtimer interrupt code contains a hang detection and mitigation
      mechanism, which prevents that a long delayed hrtimer interrupt causes a
      continous retriggering of interrupts which prevent the system from making
      progress. If a hang is detected then the timer hardware is programmed with
      a certain delay into the future and a flag is set in the hrtimer cpu base
      which prevents newly enqueued timers from reprogramming the timer hardware
      prior to the chosen delay. The subsequent hrtimer interrupt after the delay
      clears the flag and resumes normal operation.
      
      If such a hang happens in the last hrtimer interrupt before a CPU is
      unplugged then the hang_detected flag is set and stays that way when the
      CPU is plugged in again. At that point the timer hardware is not armed and
      it cannot be armed because the hang_detected flag is still active, so
      nothing clears that flag. As a consequence the CPU does not receive hrtimer
      interrupts and no timers expire on that CPU which results in RCU stalls and
      other malfunctions.
      
      Clear the flag along with some other less critical members of the hrtimer
      cpu base to ensure starting from a clean state when a CPU is plugged in.
      
      Thanks to Paul, Sebastian and Anna-Maria for their help to get down to the
      root cause of that hard to reproduce heisenbug. Once understood it's
      trivial and certainly justifies a brown paperbag.
      
      Fixes: 41d2e494 ("hrtimer: Tune hrtimer_interrupt hang logic")
      Reported-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Sebastian Sewior <bigeasy@linutronix.de>
      Cc: Anna-Maria Gleixner <anna-maria@linutronix.de>
      Cc: stable@vger.kernel.org
      Link: https://lkml.kernel.org/r/alpine.DEB.2.20.1801261447590.2067@nanos
      d5421ea4
    • H. Peter Anvin's avatar
      x86: Mark hpa as a "Designated Reviewer" for the time being · 8a95b74d
      H. Peter Anvin authored
      Due to some unfortunate events, I have not been directly involved in
      the x86 kernel patch flow for a while now.  I have also not been able
      to ramp back up by now like I had hoped to, and after reviewing what I
      will need to work on both internally at Intel and elsewhere in the near
      term, it is clear that I am not going to be able to ramp back up until
      late 2018 at the very earliest.
      
      It is not acceptable to not recognize that this load is currently
      taken by Ingo and Thomas without my direct participation, so I mark
      myself as R: (designated reviewer) rather than M: (maintainer) until
      further notice.  This is in fact recognizing the de facto situation
      for the past few years.
      
      I have obviously no intention of going away, and I will do everything
      within my power to improve Linux on x86 and x86 for Linux.  This,
      however, puts credit where it is due and reflects a change of focus.
      
      This patch also removes stale entries for portions of the x86
      architecture which have not been maintained separately from arch/x86
      for a long time.  If there is a reason to re-introduce them then that
      can happen later.
      Signed-off-by: default avatarH. Peter Anvin <h.peter.anvin@intel.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Bruce Schlobohm <bruce.schlobohm@intel.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/20180125195934.5253-1-hpa@zytor.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      8a95b74d
  4. 26 Jan, 2018 23 commits