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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 15BCBC433FE for ; Fri, 29 Oct 2021 09:23:03 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id EF25660234 for ; Fri, 29 Oct 2021 09:23:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231489AbhJ2JZa (ORCPT ); Fri, 29 Oct 2021 05:25:30 -0400 Received: from foss.arm.com ([217.140.110.172]:36244 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229991AbhJ2JZ0 (ORCPT ); Fri, 29 Oct 2021 05:25:26 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 15AEA1FB; Fri, 29 Oct 2021 02:22:58 -0700 (PDT) Received: from lakrids.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 9F9153F5A1; Fri, 29 Oct 2021 02:22:54 -0700 (PDT) Date: Fri, 29 Oct 2021 10:22:49 +0100 From: Mark Rutland To: Pawan Gupta Cc: Russell King , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Kees Cook , Andrew Morton , Masahiro Yamada , "Peter Zijlstra (Intel)" , Sami Tolvanen , Colin Ian King , Frederic Weisbecker , Mike Rapoport , YiFei Zhu , "Steven Rostedt (VMware)" , Viresh Kumar , Andrey Konovalov , Wang Kefeng , Uwe =?utf-8?Q?Kleine-K=C3=B6nig?= , Nathan Chancellor , Nick Desaulniers , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Alexei Starovoitov , Daniel Borkmann , bpf@vger.kernel.org Subject: Re: [PATCH v2 1/2] arch/Kconfig: Make CONFIG_CPU_SPECTRE available for all architectures Message-ID: <20211029092248.GA24060@lakrids.cambridge.arm.com> References: <232b692cd79e4f6e4c3ee7055b5f02792a28d2c4.1635383031.git.pawan.kumar.gupta@linux.intel.com> <20211028134918.GB48435@lakrids.cambridge.arm.com> <20211028193658.7n2oehp6yogyqbwq@gupta-dev2.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20211028193658.7n2oehp6yogyqbwq@gupta-dev2.localdomain> User-Agent: Mutt/1.11.1+11 (2f07cb52) (2018-12-01) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Oct 28, 2021 at 12:36:58PM -0700, Pawan Gupta wrote: > On 28.10.2021 14:49, Mark Rutland wrote: > > On Wed, Oct 27, 2021 at 06:33:22PM -0700, Pawan Gupta wrote: > > > Borrow CONFIG_CPU_SPECTRE from ARM to be available for all > > > architectures. This will help in configuration of features that depend > > > on CPU being affected by spectre class of vulnerabilities. > > > > > > Signed-off-by: Pawan Gupta > > > > Given that spectre isn't one specific issue, biut rather a blanket term > > for a bunch of things that can have variable overlap, I don't think this > > makes much sense unless we're going to add finer-grained options for all > > the variants, and IMO it'd make more sene for the architectures to > > directly select the things that'd otherwise be dependent on this. > > Isn't ARM already using CPU_SPECTRE for selecting things: > > config HARDEN_BRANCH_PREDICTOR > bool "Harden the branch predictor against aliasing attacks" if EXPERT > depends on CPU_SPECTRE It's true that arch/arm does, but that's not true for other architectures, e.g. powerpc or arm64, and and as above I don't think it makes sense to make this generic in its current form because "spectre" is a somewhat vague generic term. > This was the whole motivation for doing the same for x86. > > Adding a condition for all architectures is also okay, but its going to > a little messier: > > config BPF_UNPRIV_DEFAULT_OFF > default y if X86 || ARM || ... > > This approach would make sense if architectures wants to explicitly > select the defaults irrespective of architecture being affected by > spectre. If we're going to change the default for some architectures, I think it'd make much more sense to just do that for all, without any arch-specific conditionality, i.e. config BPF_UNPRIV_DEFAULT_OFF default y ... so that the behaviour is consistent across all architectures, and we don't have to play a whack-a-mole game as/when we realise architectures are affected by some variant of an issue relating to speculation. Thanks, Mark.