From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_NEOMUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 706BAC4360F for ; Fri, 5 Apr 2019 14:20:58 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 487CE205F4 for ; Fri, 5 Apr 2019 14:20:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731127AbfDEOU5 (ORCPT ); Fri, 5 Apr 2019 10:20:57 -0400 Received: from mx1.redhat.com ([209.132.183.28]:42700 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726806AbfDEOU4 (ORCPT ); Fri, 5 Apr 2019 10:20:56 -0400 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id BEC5C308FF32; Fri, 5 Apr 2019 14:20:55 +0000 (UTC) Received: from treble (ovpn-123-87.rdu2.redhat.com [10.10.123.87]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 92E925D705; Fri, 5 Apr 2019 14:20:50 +0000 (UTC) Date: Fri, 5 Apr 2019 09:20:48 -0500 From: Josh Poimboeuf To: Borislav Petkov Cc: linux-kernel@vger.kernel.org, x86@kernel.org, Thomas Gleixner , Ingo Molnar , "H . Peter Anvin" , Andy Lutomirski , Peter Zijlstra , Jiri Kosina , Waiman Long , Andrea Arcangeli , Jon Masters , Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , linuxppc-dev@lists.ozlabs.org, Martin Schwidefsky , Heiko Carstens , linux-s390@vger.kernel.org, Catalin Marinas , Will Deacon , linux-arm-kernel@lists.infradead.org, linux-arch@vger.kernel.org, Greg Kroah-Hartman , Tyler Hicks , Linus Torvalds Subject: Re: [PATCH RFC 1/5] cpu/speculation: Add 'cpu_spec_mitigations=' cmdline options Message-ID: <20190405142048.burthk2jnpcvi2om@treble> References: <20190405131211.GE23348@zn.tnic> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20190405131211.GE23348@zn.tnic> User-Agent: NeoMutt/20180716 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.49]); Fri, 05 Apr 2019 14:20:56 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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