Re: [PATCH v2 1/2] arch/Kconfig: Make CONFIG_CPU_SPECTRE available for all architectures
From: Mark Rutland <mark.rutland@arm.com>
Date: 2021-10-29 09:23:03
Also in:
linux-arm-kernel, lkml
On Thu, Oct 28, 2021 at 12:36:58PM -0700, Pawan Gupta wrote:
On 28.10.2021 14:49, Mark Rutland wrote:quoted
On Wed, Oct 27, 2021 at 06:33:22PM -0700, Pawan Gupta wrote:quoted
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@linux.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.