From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.codeaurora.org by pdx-caf-mail.web.codeaurora.org (Dovecot) with LMTP id tSAgLYTTG1u/AQAAmS7hNA ; Sat, 09 Jun 2018 13:19:29 +0000 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id AD2AF608BF; Sat, 9 Jun 2018 13:19:29 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on pdx-caf-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.0 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by smtp.codeaurora.org (Postfix) with ESMTP id 267C76074D; Sat, 9 Jun 2018 13:19:29 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 267C76074D Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753291AbeFINT1 (ORCPT + 25 others); Sat, 9 Jun 2018 09:19:27 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:40462 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753259AbeFINTZ (ORCPT ); Sat, 9 Jun 2018 09:19:25 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 477671435; Sat, 9 Jun 2018 06:19:25 -0700 (PDT) Received: from big-swifty.misterjones.org (usa-sjc-mx-foss1.foss.arm.com [217.140.101.70]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id BAFC23F557; Sat, 9 Jun 2018 06:19:19 -0700 (PDT) Date: Sat, 09 Jun 2018 14:19:10 +0100 Message-ID: <86wov885dd.wl-marc.zyngier@arm.com> From: Marc Zyngier To: Jon Masters Cc: , , , Will Deacon , Catalin Marinas , Thomas Gleixner , Andy Lutomirski , Kees Cook , Greg Kroah-Hartman , Christoffer Dall , Randy Dunlap , Dominik Brodowski , Julien Grall , Mark Rutland Subject: Re: [PATCH v2 05/17] arm64: Add 'ssbd' command-line option In-Reply-To: References: <20180529121121.24927-1-marc.zyngier@arm.com> <20180529121121.24927-6-marc.zyngier@arm.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 EasyPG/1.0.0 Emacs/25.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) Organization: ARM Ltd MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, 09 Jun 2018 13:53:08 +0100, Jon Masters wrote: > > On 05/29/2018 08:11 AM, Marc Zyngier wrote: > > > + ssbd= [ARM64,HW] > > + Speculative Store Bypass Disable control > > + > > + On CPUs that are vulnerable to the Speculative > > + Store Bypass vulnerability and offer a > > + firmware based mitigation, this parameter > > + indicates how the mitigation should be used: > > + > > + force-on: Unconditionally enable mitigation for > > + for both kernel and userspace > > + force-off: Unconditionally disable mitigation for > > + for both kernel and userspace > > + kernel: Always enable mitigation in the > > + kernel, and offer a prctl interface > > + to allow userspace to register its > > + interest in being mitigated too. > > This should be "spec_store_bypass_disable" and it should have the same > parameters as on x86: "on", "off", "auto". Why not just add > "kernel"? Feel free to propose a patch that adds the x86 compat option if you want, but I don't think this option deserves that many letters, and it is also worth realising the semantics of the mitigation *are* different. That's the real reason why we have different options. > (we had a "kernel" early on for x86 as well, and it might still end up > coming back anyway). If there's a /compelling/ reason to have the Arm > parameter differ, then it should still recognize the x86 parameter, > similarly to how POWER also does that for cross-arch consistency. Well, we should then aim for real consistency (seccomp or not seccomp? mitigated kernel or not?), and not at the cosmetic level. Once all arches implement identical behaviours, we'll be in a position to safely have a common option naming scheme which would encompass the actual meaning of "on" and "off" (which have opposite meaning between x86 and arm64). > We'll add the x86 parameter way of doing it to RHEL anyway. Great! M. -- Jazz is not dead, it just smell funny.