From: David Woodhouse <dwmw@amazon.co.uk>
To: tglx@linutronix.de, torvalds@linux-foundation.org,
x86@kernel.org, linux-kernel@vger.kernel.org, bp@alien8.de,
peterz@infradead.org, tim.c.chen@linux.intel.com,
dave.hansen@intel.com, arjan.van.de.ven@intel.com
Subject: [RFC PATCH 0/4] Retpoline / IBRS_ALL
Date: Wed, 7 Feb 2018 00:03:10 +0000 [thread overview]
Message-ID: <1517961794-14972-1-git-send-email-dwmw@amazon.co.uk> (raw)
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
next reply other threads:[~2018-02-07 0:06 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-07 0:03 David Woodhouse [this message]
2018-02-07 0:03 ` [RFC PATCH 1/4] Revert "x86/speculation: Simplify indirect_branch_prediction_barrier()" David Woodhouse
2018-02-07 0:03 ` [RFC PATCH 2/4] KVM: x86: Reduce retpoline performance impact in slot_handle_level_range() David Woodhouse
[not found] ` <1518092274.3677.177.camel@infradead.org>
2018-02-08 12:28 ` [Fwd: [RFC PATCH 2/4] KVM: x86: Reduce retpoline performance impact in slot_handle_level_range()] Sironi, Filippo
2018-02-07 0:03 ` [RFC PATCH 3/4] x86/speculation: Use IBRS if available before calling into firmware David Woodhouse
2018-02-07 11:17 ` Borislav Petkov
2018-02-07 11:29 ` David Woodhouse
2018-02-07 0:03 ` [RFC PATCH 4/4] x86/speculation: Support "Enhanced IBRS" on future CPUs David Woodhouse
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1517961794-14972-1-git-send-email-dwmw@amazon.co.uk \
--to=dwmw@amazon.co.uk \
--cc=arjan.van.de.ven@intel.com \
--cc=bp@alien8.de \
--cc=dave.hansen@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=tim.c.chen@linux.intel.com \
--cc=torvalds@linux-foundation.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®