LKML Archive on
help / color / mirror / Atom feed
From: "Maciej S. Szmigiero" <>
To: Dave Hansen <>
Cc: Thomas Gleixner <>,
	Ingo Molnar <>, "H. Peter Anvin" <>,
	David Woodhouse <>,
	KarimAllah Ahmed <>,
	Andi Kleen <>,
	Tim Chen <>,,,
Subject: Re: [PATCH] x86/speculation: Fill the RSB on context switch also on non-IBPB CPUs
Date: Sat, 24 Mar 2018 00:11:24 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On 22.03.2018 16:46, Dave Hansen wrote:
> On 03/21/2018 05:09 PM, Maciej S. Szmigiero wrote:
>> As far as I understand the issue this should provide a good protection
>> for userspace processes that were recompiled with retpolines as they
>> won't have any indirect jumps and calls.
> Instead of saying "good protection", let's just say that it could
> mitigate attacks that require consumption of attacker-placed RSB entries.

All right.

>>> Do you perhaps want to do RSB manipulation in lieu of IBPB when
>>> switching *to* a non-dumpable process and IBPB is not available?
>> Is it worth differentiating such processes in this case?
>> IBPB is supposed to be very expensive so certainly it is worthwhile
>> to do it only for high-value processes (=non-dumpable).
>> However, it is unlikely that existing RSB entries from the previous
>> task match the new task call stack anyway.
>> We already do unconditional RSB-filling-on-context-switch in many
>> cases.
> I think this case is a bit too obscure and theoretical to complicate the
> kernel with it.  You need an unmitigated processor, a
> userspace-to-userspace attack that manages to satisfy the five "exploit
> composition" steps of Spectre/V2[1], and an application that has been
> retpoline-mitigated.
> While RSB manipulation is almost certainly less onerous than IBPB, it's
> still going to hurt context-switch rates, especially if applied
> indiscriminately like this patch does.
> So, I totally agree with your analysis about the theoretical potential
> for an issue, I'm just not really convinced the fix is worth it.

Yes, Spectre v2 looks really hard to exploit, but this doesn't mean the
kernel shouldn't do its best to mitigate it.

As I wrote two messages ago, basing on the Intel guidance document you
linked above as "[1]" I think that the mitigation introduced by this
patch should not be done on Intel CPUs, however, since that document
clearly suggests that this may not be enough to cover the issue.
And I think we shouldn't give people a false sense of security.


      reply	other threads:[~2018-03-23 23:11 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-20 11:17 Maciej S. Szmigiero
2018-03-21 14:05 ` Dave Hansen
2018-03-21 22:57   ` Maciej S. Szmigiero
2018-03-21 23:30 ` Dave Hansen
2018-03-22  0:09   ` Maciej S. Szmigiero
2018-03-22 15:46     ` Dave Hansen
2018-03-23 23:11       ` Maciej S. Szmigiero [this message]

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \
    --subject='Re: [PATCH] x86/speculation: Fill the RSB on context switch also on non-IBPB CPUs' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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).