From: Linus Torvalds <email@example.com>
To: Ingo Molnar <firstname.lastname@example.org>
Cc: Linux Kernel Mailing List <email@example.com>,
Thomas Gleixner <firstname.lastname@example.org>,
Borislav Petkov <email@example.com>,
Peter Zijlstra <firstname.lastname@example.org>,
Andrew Morton <email@example.com>,
Andy Lutomirski <firstname.lastname@example.org>
Subject: Re: [GIT PULL] x86/mm changes for v5.8
Date: Mon, 1 Jun 2020 14:42:59 -0700 [thread overview]
Message-ID: <CAHk-=wgXf_wQ9zrJKv2Hy4EpEbLuqty-Cjbs2u00gm7XcYHBfw@mail.gmail.com> (raw)
On Mon, Jun 1, 2020 at 10:01 AM Ingo Molnar <email@example.com> wrote:
> - Provide an opt-in (prctl driven) mechanism to flush the L1D cache on context switch.
> The goal is to allow tasks that are paranoid due to the recent snoop assisted data
> sampling vulnerabilites, to flush their L1D on being switched out.
Am I mis-reading this?
Because it looks to me like this basically exports cache flushing
instructions to user space, and gives processes a way to just say
"slow down anybody else I schedule with too".
I don't see a way for a system admin to say "this is stupid, don't do it".
In other words, from what I can tell, this takes the crazy "Intel
ships buggy CPU's and it causes problems for virtualization" code
(which I didn't much care about), and turns it into "anybody can opt
in to this disease, and now it affects even people and CPU's that
don't need it and configurations where it's completely pointless".
To make matters worse, it has that SW flushing fallback that isn't
even architectural from what I remember of the last time it was
discussed, but most certainly will waste a lot of time going through
the motions that may or may not flush the L1D after all.
I don't want some application to go "Oh, I'm _soo_ special and pretty
and such a delicate flower, that I want to flush the L1D on every task
switch, regardless of what CPU I am on, and regardless of whether
there are errata or not".
Because that app isn't just slowing down itself, it's slowing down others too.
I have a hard time following whether this might all end up being
predicated on the STIBP static branch conditionals and might thus at
least be limited only to CPU's that have the problem in the first
But I ended up unpulling it because I can't figure that out, and the
explanations in the commits don't clarify (and do imply that it's
regardless of any other errata, since it's for "undiscovered future
Because I don't want a random "I can make the kernel do stupid things"
flag for people to opt into. I think it needs a double opt-in.
At a _minimum_, SMT being enabled should disable this kind of crazy
pseudo-security entirely, since it is completely pointless in that
situation. Scheduling simply isn't a synchronization point with SMT
on, so saying "sure, I'll flush the L1 at context switch" is beyond
I do not want the kernel to do things that seem to be "beyond stupid".
Because I really think this is just PR and pseudo-security, and I
think there's a real cost in making people think "oh, I'm so special
that I should enable this".
I'm more than happy to be educated on why I'm wrong, but for now I'm
unpulling it for lack of data.
Maybe it never happens on SMT because of all those subtle static
branch rules, but I'd really like to that to be explained.
next prev parent reply other threads:[~2020-06-01 21:43 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-01 17:01 [GIT PULL] x86/mm changes for v5.8 Ingo Molnar
2020-06-01 21:42 ` Linus Torvalds [this message]
2020-06-02 2:35 ` Linus Torvalds
2020-06-02 10:25 ` Singh, Balbir
2020-06-02 7:33 ` Ingo Molnar
2020-06-02 9:37 ` Benjamin Herrenschmidt
2020-06-02 18:28 ` Thomas Gleixner
2020-06-02 19:14 ` Linus Torvalds
2020-06-02 23:01 ` Singh, Balbir
2020-06-02 23:28 ` Linus Torvalds
2020-06-03 1:31 ` Singh, Balbir
2020-06-04 17:29 ` [GIT PULL v2] " Ingo Molnar
2020-06-05 2:41 ` Linus Torvalds
2020-06-05 8:11 ` [GIT PULL v3] " Ingo Molnar
2020-06-05 20:40 ` pr-tracker-bot
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 \
* 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).