linux-kernel - Re: [PATCH 1/2] cpu: Re-enable CPU mitigations by default for !X86 architectures

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: <ZiKgAh1aNBGHpOof@google.com>
Date: Fri, 19 Apr 2024 09:46:58 -0700
From: Sean Christopherson <seanjc@...gle.com>
To: Josh Poimboeuf <jpoimboe@...nel.org>
Cc: Jonathan Corbet <corbet@....net>, 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, 
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Peter Zijlstra <peterz@...radead.org>, 
	linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org, 
	Stephen Rothwell <sfr@...b.auug.org.au>, Michael Ellerman <mpe@...erman.id.au>, 
	Geert Uytterhoeven <geert@...ux-m68k.org>
Subject: Re: [PATCH 1/2] cpu: Re-enable CPU mitigations by default for !X86 architectures

On Fri, Apr 19, 2024, Josh Poimboeuf wrote:
> On Tue, Apr 16, 2024 at 05:15:06PM -0700, Sean Christopherson wrote:
> > Add a generic Kconfig, CPU_MITIGATIONS, to control whether or not CPU
> > mitigations are enabled by default, and force it on for all architectures
> > except x86.  A recent commit to turn mitigations off by default if
> > SPECULATION_MITIGATIONS=n kinda sorta missed that "cpu_mitigations" is
> > completely generic, where as SPECULATION_MITIGATIONS is x86 specific.
> > 
> > Alternatively, SPECULATION_MITIGATIONS could simply be defined in common
> > code, but that creates weirdness for x86 because SPECULATION_MITIGATIONS
> > ends up being defined twice, and the default behavior would likely depend
> > on the arbitrary include order (if the two definitions diverged).
> > 
> > Ideally, CPU_MITIGATIONS would be unconditionally on by default for all
> > architectures, and manually turned off, but there is no way to unselect a
> > Kconfig.
> > 
> > Reported-by: Stephen Rothwell <sfr@...b.auug.org.au>
> > Reported-by: Michael Ellerman <mpe@...erman.id.au>
> > Reported-by: Geert Uytterhoeven <geert@...ux-m68k.org>
> > Closes: https://lkml.kernel.org/r/20240413115324.53303a68%40canb.auug.org.au
> > Fixes: f337a6a21e2f ("x86/cpu: Actually turn off mitigations by default for SPECULATION_MITIGATIONS=n")
> > Cc: stable@...r.kernel.org
> > Signed-off-by: Sean Christopherson <seanjc@...gle.com>
> 
> It seems confusing to have two config options which have very similar
> names and similar purposes (with subtle differences depending on the
> arch).
> 
> How about we instead just get rid of the x86-specific
> SPECULATION_MITIGATIONS and replace it with a menu which depends on
> CPU_MITIGATIONS:

Huh, didn't realize that was possible.

I agree that having two things for the same thing is confusing, though Boris'
idea to do s/SPECULATION_MITIGATIONS/X86_CPU_MITIGATIONS would help a fair bit
on that front.

My only hesitation is that x86's menu and the common config knob end up in
completely different locations.  And AFAICT, the parser doesn't allow sourcing
menu entires from a different file:

  init/Kconfig:1959: 'menu' in different file than 'menu'

e.g. we can't declare the menuconfig in common code and then include arch
definitions.

Regardless of whether or not we shuffle things around, CPU_MITIGATIONS really
should be in init/Kconfig, not drivers/base/Kconfig, e.g. so that if we make it
a user-selectable option, it shows up under "General setup" instead of being
buried two layers deep in drivers.

That makes it less hard to find CPU_MITIGATIONS, but I still find it cumbersome
to have to enable CPU_MITIGATIONS, and then go hunting for x86's menu.