LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Dave Hansen <firstname.lastname@example.org>
To: "Maciej S. Szmigiero" <email@example.com>
Cc: Thomas Gleixner <firstname.lastname@example.org>,
Ingo Molnar <email@example.com>, "H. Peter Anvin" <firstname.lastname@example.org>,
David Woodhouse <email@example.com>,
KarimAllah Ahmed <firstname.lastname@example.org>,
Andi Kleen <email@example.com>,
Tim Chen <firstname.lastname@example.org>,
Subject: Re: [PATCH] x86/speculation: Fill the RSB on context switch also on non-IBPB CPUs
Date: Thu, 22 Mar 2018 08:46:20 -0700 [thread overview]
Message-ID: <email@example.com> (raw)
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.
>> 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
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, and an application that has been
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.
next prev parent reply other threads:[~2018-03-22 15:46 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 [this message]
2018-03-23 23:11 ` Maciej S. Szmigiero
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).