From: Tom Lendacky <thomas.lendacky@amd.com>
To: David Woodhouse <dwmw@amazon.co.uk>,
tglx@linutronix.de, karahmed@amazon.de, x86@kernel.org,
kvm@vger.kernel.org, torvalds@linux-foundation.org,
pbonzini@redhat.com, linux-kernel@vger.kernel.org, bp@alien8.de,
peterz@infradead.org, jmattson@google.com, rkrcmar@redhat.com,
arjan.van.de.ven@intel.com, dave.hansen@intel.com,
mingo@kernel.org
Subject: Re: [PATCH 1/4] x86/speculation: Use IBRS if available before calling into firmware
Date: Wed, 14 Feb 2018 10:07:02 -0600 [thread overview]
Message-ID: <6e3610be-cdcb-5c5c-fecc-7c41f2ebda73@amd.com> (raw)
In-Reply-To: <1518615874-13806-2-git-send-email-dwmw@amazon.co.uk>
On 2/14/2018 7:44 AM, David Woodhouse wrote:
> Retpoline means the kernel is safe because it has no indirect branches.
> But firmware isn't, so use IBRS for firmware calls if it's available.
>
> Block preemption while IBRS is set, although in practice the call sites
> already had to be doing that.
>
> Ignore hpwdt.c for now. It's taking spinlocks and calling into firmware
> code, from an NMI handler. I don't want to touch that with a bargepole.
>
> Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
> ---
> arch/x86/include/asm/apm.h | 6 ++++++
> arch/x86/include/asm/cpufeatures.h | 1 +
> arch/x86/include/asm/efi.h | 17 ++++++++++++++--
> arch/x86/include/asm/nospec-branch.h | 39 +++++++++++++++++++++++++++---------
> arch/x86/kernel/cpu/bugs.c | 12 ++++++++++-
> 5 files changed, 63 insertions(+), 12 deletions(-)
>
... <snip> ...
> +/*
> + * With retpoline, we must use IBRS to restrict branch prediction
> + * before calling into firmware.
> + */
> +static inline void firmware_restrict_branch_speculation_start(void)
> +{
> + preempt_disable();
> + alternative_msr_write(MSR_IA32_SPEC_CTRL, SPEC_CTRL_IBRS,
> + X86_FEATURE_USE_IBRS_FW);
> +}
> +
> +static inline void firmware_restrict_branch_speculation_end(void)
> +{
> + alternative_msr_write(MSR_IA32_SPEC_CTRL, 0,
> + X86_FEATURE_USE_IBRS_FW);
> + preempt_enable();
> }
Shouldn't these writes to the MSR be just for the IBRS bit? The spec
also defines the STIBP bit for this MSR, and if that bit had been set by
BIOS for example, these writes will clear it. And who knows what future
bits may be defined and how they'll be used.
Thanks,
Tom
>
> #endif /* __ASSEMBLY__ */
> diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
> index d71c8b5..bfca937 100644
> --- a/arch/x86/kernel/cpu/bugs.c
> +++ b/arch/x86/kernel/cpu/bugs.c
> @@ -300,6 +300,15 @@ static void __init spectre_v2_select_mitigation(void)
> setup_force_cpu_cap(X86_FEATURE_USE_IBPB);
> pr_info("Spectre v2 mitigation: Enabling Indirect Branch Prediction Barrier\n");
> }
> +
> + /*
> + * Retpoline means the kernel is safe because it has no indirect
> + * branches. But firmware isn't, so use IBRS to protect that.
> + */
> + if (boot_cpu_has(X86_FEATURE_IBRS)) {
> + setup_force_cpu_cap(X86_FEATURE_USE_IBRS_FW);
> + pr_info("Enabling Restricted Speculation for firmware calls\n");
> + }
> }
>
> #undef pr_fmt
> @@ -326,8 +335,9 @@ ssize_t cpu_show_spectre_v2(struct device *dev, struct device_attribute *attr, c
> if (!boot_cpu_has_bug(X86_BUG_SPECTRE_V2))
> return sprintf(buf, "Not affected\n");
>
> - return sprintf(buf, "%s%s%s\n", spectre_v2_strings[spectre_v2_enabled],
> + return sprintf(buf, "%s%s%s%s\n", spectre_v2_strings[spectre_v2_enabled],
> boot_cpu_has(X86_FEATURE_USE_IBPB) ? ", IBPB" : "",
> + boot_cpu_has(X86_FEATURE_USE_IBRS_FW) ? ", IBRS_FW" : "",
> spectre_v2_module_string());
> }
> #endif
>
next prev parent reply other threads:[~2018-02-14 16:07 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-14 13:44 [PATCH 0/4] Speculation control improvements David Woodhouse
2018-02-14 13:44 ` [PATCH 1/4] x86/speculation: Use IBRS if available before calling into firmware David Woodhouse
2018-02-14 16:07 ` Tom Lendacky [this message]
2018-02-14 16:11 ` David Woodhouse
2018-02-14 16:36 ` Tom Lendacky
2018-02-14 16:53 ` David Woodhouse
2018-02-14 13:44 ` [PATCH 2/4] x86/speculation: Support "Enhanced IBRS" on future CPUs David Woodhouse
2018-02-14 13:44 ` [PATCH 3/4] Revert "x86/retpoline: Simplify vmexit_fill_RSB()" David Woodhouse
2018-02-14 13:44 ` [PATCH 4/4] x86/retpoline: Support retpoline build with Clang 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=6e3610be-cdcb-5c5c-fecc-7c41f2ebda73@amd.com \
--to=thomas.lendacky@amd.com \
--cc=arjan.van.de.ven@intel.com \
--cc=bp@alien8.de \
--cc=dave.hansen@intel.com \
--cc=dwmw@amazon.co.uk \
--cc=jmattson@google.com \
--cc=karahmed@amazon.de \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=rkrcmar@redhat.com \
--cc=tglx@linutronix.de \
--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