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=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS, URIBL_BLOCKED,USER_AGENT_NEOMUTT autolearn=unavailable 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 76DB6C4360F for ; Fri, 5 Apr 2019 14:21:02 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 3FF0420989 for ; Fri, 5 Apr 2019 14:21:02 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="CNqqHrlU" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3FF0420989 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=Lku0ver93vuuJNEnHx+nKyPLMpA47xmg2IyTyIG5QBM=; b=CNqqHrlUg8fG+G O2ZSWBHOWfzINfSP0+DNsHsFilmH4wtrW8az7OD7R4S//cmvaPz5CYu+P7yzDRkEA/0ybHiciyfqX hft4yryldJM66gq1/G2PY0n5awjin6IoWbIDYfwVFCyCQsnE2dTdWMjlJ8ECh90kxhFYs0fn8Huz9 57RmfYKDTX22nM3F1fmUztbNkyWvRvd2y4S9iaQQpXj1p1BzgrHQ0inLXVGMeLhbyAGz+ybECCOU/ rx3JO886JH96DLPdwwp11qddp6kQww4db0HfNZjKcYFPxwvhGvZgvYQSG+QdPLb9NOPFTymUmmIeo HLfnVyvbg4Vkg3EJGxtA==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1hCPiF-0000Y0-VD; Fri, 05 Apr 2019 14:20:59 +0000 Received: from mx1.redhat.com ([209.132.183.28]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1hCPiC-0000XY-PD for linux-arm-kernel@lists.infradead.org; Fri, 05 Apr 2019 14:20:58 +0000 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 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-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) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190405_072056_862106_BF03F9F6 X-CRM114-Status: GOOD ( 22.48 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Peter Zijlstra , Benjamin Herrenschmidt , Heiko Carstens , Paul Mackerras , "H . Peter Anvin" , Ingo Molnar , Andrea Arcangeli , linux-s390@vger.kernel.org, Michael Ellerman , x86@kernel.org, Will Deacon , Linus Torvalds , Catalin Marinas , Waiman Long , linux-arch@vger.kernel.org, Jon Masters , Jiri Kosina , Andy Lutomirski , Thomas Gleixner , linux-arm-kernel@lists.infradead.org, Greg Kroah-Hartman , linux-kernel@vger.kernel.org, Tyler Hicks , Martin Schwidefsky , linuxppc-dev@lists.ozlabs.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel