linux-kernel - Re: [PATCH RFC 1/5] cpu/speculation: Add 'cpu_spec

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] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 5 Apr 2019 09:20:48 -0500
From:   Josh Poimboeuf <jpoimboe@...hat.com>
To:     Borislav Petkov <bp@...en8.de>
Cc:     linux-kernel@...r.kernel.org, x86@...nel.org,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...nel.org>,
        "H . Peter Anvin" <hpa@...or.com>,
        Andy Lutomirski <luto@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Jiri Kosina <jikos@...nel.org>,
        Waiman Long <longman@...hat.com>,
        Andrea Arcangeli <aarcange@...hat.com>,
        Jon Masters <jcm@...hat.com>,
        Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        Paul Mackerras <paulus@...ba.org>,
        Michael Ellerman <mpe@...erman.id.au>,
        linuxppc-dev@...ts.ozlabs.org,
        Martin Schwidefsky <schwidefsky@...ibm.com>,
        Heiko Carstens <heiko.carstens@...ibm.com>,
        linux-s390@...r.kernel.org,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will.deacon@....com>,
        linux-arm-kernel@...ts.infradead.org, linux-arch@...r.kernel.org,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Tyler Hicks <tyhicks@...onical.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH RFC 1/5] cpu/speculation: Add 'cpu_spec_mitigations='
 cmdline options

On Fri, Apr 05, 2019 at 03:12:11PM +0200, Borislav Petkov wrote:
> On Thu, Apr 04, 2019 at 11:44:11AM -0500, Josh Poimboeuf wrote:
> > Keeping track of the number of mitigations for all the CPU speculation
> > bugs has become overwhelming for many users.  It's getting more and more
> > complicated to decide which mitigations are needed for a given
> > architecture.  Complicating matters is the fact that each arch tends to
> > their own custom way to mitigate the same vulnerability.
> 
> Yap, we definitely need something like that.
> 
> > Most users fall into a few basic categories:
> > 
> > a) they want all mitigations off;
> > 
> > b) they want all reasonable mitigations on, with SMT enabled even if
> >    it's vulnerable; or
> 
> Uff, "reasonable" - there's the bikeshed waiting to happen.

Luckily the defaults have already been chosen.  So "reasonable" just
means to use the defaults.

> > c) they want all reasonable mitigations on, with SMT disabled if
> >    vulnerable.
> > 
> > Define a set of curated, arch-independent options, each of which is an
> > aggregation of existing options:
> > 
> > - cpu_spec_mitigations=off: Disable all mitigations.
> 
> "cpu_spec_mitigations" is too long, TBH.
> 
> Imagine yourself in a loud, noisy data center - you basically can't wait
> to leave - crouched over a keyboard in an impossible position, having
> to type that thing and then making a typo. Whoops, too late, already
> pressed Enter. Shiiiit!

Sure, it's a bit long.  But it's also easier to remember and more
self-documenting than any shortened option I could come up with.

In your scenario, the fact that it's so easy to remember would save the
day, since you wouldn't have to go look up some obscure shortened option
name in the documentation :-)

Suggestions are welcome but I couldn't come up with a reasonable shorter
option.

> Now you have to wait at least 15 mins for the damn single-threaded added
> value BIOS crap to noodle through all the cores just so you can try
> again, because you just rebooted the box.
> 
> And I know, my ideas for shorter cmdline options are crazy, like
> 
> cpu_spec_mtg=
> 
> which people would say, yuck, unreadable...

I agree with those people.  In my world "mtg" is short for meeting.

> Oh, I know! How about
> 
> cpu_vulns=
> 
> ?

No, because

a) We aren't enabling/disabling *vulnerabilities*, but rather
   mitigations;

b) We aren't enabling/disabling *all* CPU mitigations, only the
   speculative ones.

> We already have /sys/devices/system/cpu/vulnerabilities so it'll be the
> same as that. Less things to remember.

Except that it's not called "cpu_vulns"...

-- 
Josh