linux-kernel - Re: [Patch v6 14/16] x86/speculation: Use STIBP to restrict speculation on non-dumpable task

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAHk-=wi0T95H8e290pJ0xUboyjsj-abePin6sO1vLhGE1JPyfQ@mail.gmail.com>
Date:   Wed, 21 Nov 2018 12:26:01 -0800
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     dave.hansen@...el.com
Cc:     Tim Chen <tim.c.chen@...ux.intel.com>,
        Jiri Kosina <jikos@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>, thomas.lendacky@....com,
        Ingo Molnar <mingo@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        Andrea Arcangeli <aarcange@...hat.com>,
        David Woodhouse <dwmw@...zon.co.uk>,
        Andi Kleen <ak@...ux.intel.com>,
        Casey Schaufler <casey.schaufler@...el.com>,
        "Mallick, Asit K" <asit.k.mallick@...el.com>,
        "Van De Ven, Arjan" <arjan@...ux.intel.com>, jcm@...hat.com,
        longman9394@...il.com, Greg KH <gregkh@...uxfoundation.org>,
        david.c.stewart@...el.com,
        Linux List Kernel Mailing <linux-kernel@...r.kernel.org>,
        "the arch/x86 maintainers" <x86@...nel.org>, stable@...r.kernel.org
Subject: Re: [Patch v6 14/16] x86/speculation: Use STIBP to restrict
 speculation on non-dumpable task

On Wed, Nov 21, 2018 at 12:07 PM Dave Hansen <dave.hansen@...el.com> wrote:
>
> Repurposing dumpable is really screwy and surely imprecise, but it
> really is the closest thing that we have without the new ABI.

But we *have* a new ABI.

So that's not a valid argument.

It's more like "this other thing that some other users use for
something *entirely* different has in _one_ case the semantics you'd
want, but in most cases not at all".

Because gpg really is the odd man out.

And it's not at all obvious that you can attack gpg using the hole
that STIBP opens, when there are other timing attacks that are likely
as good or better, and when we know that people who really care about
the issue are already just disabling SMT entirely.

That's really the basic issue here: STIBP has horrible overhead, _and_
it's not even targeting the people who really want it, so we'd better
be very targeted in how it's used.

Because we already know how badly things messed up when the use of
STIBP wasn't targeted.

The _only_ very real and direct advantage "dumpable" has is that it
hides the problem from benchmarks. Because benchmarks don't test
non-dumpable processes.

But honestly, that sounds like a disadvantage to me. It smells like
"let's hide the overhead dishonestly".

                 Linus