lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <1517961794-14972-1-git-send-email-dwmw@amazon.co.uk>
Date:   Wed,  7 Feb 2018 00:03:10 +0000
From:   David Woodhouse <dwmw@...zon.co.uk>
To:     tglx@...utronix.de, torvalds@...ux-foundation.org, x86@...nel.org,
        linux-kernel@...r.kernel.org, bp@...en8.de, peterz@...radead.org,
        tim.c.chen@...ux.intel.com, dave.hansen@...el.com,
        arjan.van.de.ven@...el.com
Subject: [RFC PATCH 0/4] Retpoline / IBRS_ALL

Using retpoline ensures the kernel is safe because it doesn't contain
any indirect branches, but firmware still can — and we make calls into
firmware at runtime. Where the IBRS microcode support is available, use
that before calling into firmware.

While doing that, I noticed that we were calling C functions without
telling the compiler about the call-clobbered registers. Stop that.

This also contains the always_inline fix for the performance problem 
introduced by retpoline in KVM code, and finally adds IBRS_ALL support 
for future CPUs, where we can disable the retpoline but still want to 
use IBPB on context switch etc. I'll repeat the comment from that commit 
here, for clarity:

This does not actually *set* the IBRS bit in the SPEC_CTRL register,
because Intel's documentation is wrong. Not wrong in the sense of
"does not accurately describe Intel's planned future hardware", but
more in the sense that if Intel make hardware like that, then they
are Doing It Wrong™.

With IBRS_ALL advertised in IA32_ARCH_CAPABILITIES, the IBRS bit in
the MSR should do *nothing*. The safe mode where the CPU honours the
tags in the BTB/RSB should be enabled *unconditionally*.


David Woodhouse (4):
  Revert "x86/speculation: Simplify indirect_branch_prediction_barrier()"
  KVM: x86: Reduce retpoline performance impact in slot_handle_level_range()
  x86/speculation: Use IBRS if available before calling into firmware
  x86/speculation: Support "Enhanced IBRS" on future CPUs

 arch/x86/include/asm/apm.h           |  6 ++++++
 arch/x86/include/asm/cpufeatures.h   |  1 +
 arch/x86/include/asm/efi.h           | 13 +++++++++++--
 arch/x86/include/asm/nospec-branch.h | 34 +++++++++++++++++++++++++++++-----
 arch/x86/include/asm/processor.h     |  3 ---
 arch/x86/kernel/cpu/bugs.c           | 29 ++++++++++++++++++++++-------
 arch/x86/kvm/mmu.c                   | 10 +++++-----
 drivers/watchdog/hpwdt.c             |  3 +++
 8 files changed, 77 insertions(+), 22 deletions(-)

-- 
2.7.4

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ