Thread (6 messages) 6 messages, 4 authors, 2021-10-29

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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help