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]
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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ