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@xxxxxxxxxxxxxxx> > > > > 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.
