From: Tim Chen <tim.c.chen@linux.intel.com>
To: Jiri Kosina <jikos@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>,
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
Borislav Petkov <bp@suse.de>, David Woodhouse <dwmw@amazon.co.uk>,
Peter Zijlstra <peterz@infradead.org>,
Linus Torvalds <torvalds@linux-foundation.org>
Cc: linux-kernel@vger.kernel.org,
Josh Poimboeuf <jpoimboe@redhat.com>,
x86@kernel.org
Subject: Re: [PATCH v2] x86/bugs: protect against userspace-userspace spectreRSB
Date: Mon, 30 Jul 2018 10:56:55 -0700 [thread overview]
Message-ID: <8329a551-ccc1-248a-2e3d-194f7c832b7e@linux.intel.com> (raw)
In-Reply-To: <nycvar.YFH.7.76.1807261308190.997@cbobk.fhfr.pm>
On 07/26/2018 04:14 AM, Jiri Kosina wrote:
> From: Jiri Kosina <jkosina@suse.cz>
>
> The article "Spectre Returns! Speculation Attacks using the Return Stack
> Buffer" [1] describes two new (sub-)variants of spectrev2-like attack,
> making use solely of the RSB contents even on CPUs that don't fallback to
> BTB on RSB underflow (Skylake+).
>
> Mitigate userspace-userspace attacks by always unconditionally filling RSB on
> context switch when generic spectrev2 mitigation has been enabled.
>
> [1] https://arxiv.org/pdf/1807.07940.pdf
>
> Reviewed-by: Josh Poimboeuf <jpoimboe@redhat.com>
> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
> ---
>
> v1 -> v2:
>
> - Fixed typos/capatalization in SpectreRSB name
> - Josh's Reviewed-by
>
> arch/x86/kernel/cpu/bugs.c | 38 +++++++-------------------------------
> 1 file changed, 7 insertions(+), 31 deletions(-)
>
> diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
> index 5c0ea39311fe..bc8c43b22460 100644
> --- a/arch/x86/kernel/cpu/bugs.c
> +++ b/arch/x86/kernel/cpu/bugs.c
> @@ -313,23 +313,6 @@ static enum spectre_v2_mitigation_cmd __init spectre_v2_parse_cmdline(void)
> return cmd;
> }
>
> -/* Check for Skylake-like CPUs (for RSB handling) */
> -static bool __init is_skylake_era(void)
> -{
> - if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL &&
> - boot_cpu_data.x86 == 6) {
> - switch (boot_cpu_data.x86_model) {
> - case INTEL_FAM6_SKYLAKE_MOBILE:
> - case INTEL_FAM6_SKYLAKE_DESKTOP:
> - case INTEL_FAM6_SKYLAKE_X:
> - case INTEL_FAM6_KABYLAKE_MOBILE:
> - case INTEL_FAM6_KABYLAKE_DESKTOP:
> - return true;
> - }
> - }
> - return false;
> -}
> -
> static void __init spectre_v2_select_mitigation(void)
> {
> enum spectre_v2_mitigation_cmd cmd = spectre_v2_parse_cmdline();
> @@ -390,22 +373,15 @@ static void __init spectre_v2_select_mitigation(void)
> pr_info("%s\n", spectre_v2_strings[mode]);
>
> /*
> - * If neither SMEP nor PTI are available, there is a risk of
> - * hitting userspace addresses in the RSB after a context switch
> - * from a shallow call stack to a deeper one. To prevent this fill
> - * the entire RSB, even when using IBRS.
> + * If spectre v2 protection has been enabled, unconditionally fill
> + * RSB during a context switch; this protects against two independent
> + * issues:
> *
> - * Skylake era CPUs have a separate issue with *underflow* of the
> - * RSB, when they will predict 'ret' targets from the generic BTB.
> - * The proper mitigation for this is IBRS. If IBRS is not supported
> - * or deactivated in favour of retpolines the RSB fill on context
> - * switch is required.
> + * - RSB underflow (and switch to BTB) on Skylake+
> + * - SpectreRSB variant of spectre v2 on X86_BUG_SPECTRE_V2 CPUs
> */
> - if ((!boot_cpu_has(X86_FEATURE_PTI) &&
> - !boot_cpu_has(X86_FEATURE_SMEP)) || is_skylake_era()) {
> - setup_force_cpu_cap(X86_FEATURE_RSB_CTXSW);
> - pr_info("Spectre v2 mitigation: Filling RSB on context switch\n");
> - }
> + setup_force_cpu_cap(X86_FEATURE_RSB_CTXSW);
> + pr_info("Spectre v2 / SpectreRSB mitigation: Filling RSB on context switch\n");
>
> /* Initialize Indirect Branch Prediction Barrier if supported */
> if (boot_cpu_has(X86_FEATURE_IBPB)) {
>
Thanks for the patch. Looks good.
Acked-by: Tim Chen <tim.c.chen@linux.intel.com>
Tim
next prev parent reply other threads:[~2018-07-30 17:57 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-24 19:53 [PATCH] x86/bugs: protect against userspace-userspace spectreRSB Jiri Kosina
2018-07-25 13:45 ` Josh Poimboeuf
2018-07-25 13:50 ` Jiri Kosina
2018-07-25 17:11 ` Josh Poimboeuf
2018-07-30 17:59 ` Tim Chen
2018-07-25 17:28 ` Linus Torvalds
2018-07-25 23:11 ` Jiri Kosina
2018-07-25 23:27 ` Josh Poimboeuf
2018-07-26 11:14 ` [PATCH v2] " Jiri Kosina
2018-07-30 17:56 ` Tim Chen [this message]
2018-07-30 19:13 ` Konrad Rzeszutek Wilk
2018-07-30 22:48 ` [tip:x86/pti] x86/speculation: Protect " tip-bot for Jiri Kosina
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=8329a551-ccc1-248a-2e3d-194f7c832b7e@linux.intel.com \
--to=tim.c.chen@linux.intel.com \
--cc=bp@suse.de \
--cc=dwmw@amazon.co.uk \
--cc=jikos@kernel.org \
--cc=jpoimboe@redhat.com \
--cc=konrad.wilk@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--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;
as well as URLs for NNTP newsgroup(s).