linux-kernel - Re: [PATCH v2 1/2] arch/Kconfig: Make CONFIG_CPU

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]

Message-ID: <20211029092248.GA24060@lakrids.cambridge.arm.com>
Date:   Fri, 29 Oct 2021 10:22:49 +0100
From:   Mark Rutland <mark.rutland@....com>
To:     Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>
Cc:     Russell King <linux@...linux.org.uk>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org,
        "H. Peter Anvin" <hpa@...or.com>,
        Kees Cook <keescook@...omium.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Masahiro Yamada <masahiroy@...nel.org>,
        "Peter Zijlstra (Intel)" <peterz@...radead.org>,
        Sami Tolvanen <samitolvanen@...gle.com>,
        Colin Ian King <colin.king@...onical.com>,
        Frederic Weisbecker <frederic@...nel.org>,
        Mike Rapoport <rppt@...nel.org>,
        YiFei Zhu <yifeifz2@...inois.edu>,
        "Steven Rostedt (VMware)" <rostedt@...dmis.org>,
        Viresh Kumar <viresh.kumar@...aro.org>,
        Andrey Konovalov <andreyknvl@...il.com>,
        Wang Kefeng <wangkefeng.wang@...wei.com>,
        Uwe Kleine-König 
        <u.kleine-koenig@...gutronix.de>,
        Nathan Chancellor <nathan@...nel.org>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>, bpf@...r.kernel.org
Subject: Re: [PATCH v2 1/2] arch/Kconfig: Make CONFIG_CPU_SPECTRE available
 for all architectures

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 <pawan.kumar.gupta@...ux.intel.com>
> > 
> > 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.