Re: [PATCH v3 20/35] x86/bugs: Define attack vectors

[Josh Poimboeuf]

On Mon, Feb 17, 2025 at 05:33:24PM +0000, Kaplan, David wrote:
> So actually this doesn't quite work because the code in
> arch/x86/mm/pti.c has to call cpu_mitigate_attack_vector in order to
> check if PTI is required (it checks if user->kernel mitigations are
> needed).  That's the only use of the attack vectors outside of bugs.c.
> 
> The original code (using a function and WARN_ON_ONCE) can work, or I
> could perhaps create a pti-specific function in bugs.c that the pti
> code can query.  But right now I don't think there is any pti-related
> code in bugs.c at all.
> 
> Any suggestion?

Hm.  We *could* put the cpu_mitigate_attack_vector() macro in bugs.h and
make the array global (and possibly exported).  That way anybody could
call it, but it would still have the compile-time check.


However... should these not actually be arch-generic options, like
mitigations= already is?  It would make for a more consistent user
interface across arches.

They could even be integrated into the "mitigations=" interface.  The
options could be combined in any order (separated by commas):

  mitigations=user_kernel,user_user
  mitigations=guest_host,user_kernel
  ...etc...

And e.g., "mitigations=off" would simply disable all the vectors.

That would remove ambiguity created by combining mitigations= with
mitigate_* and would make it easier for all the current
cpu_mitigations_off() callers: only one global enable/disable interface
to call instead of two.  Any code calling cpu_mitigations_off() should
probably be calling something like cpu_mitigate_attack_vector() instead.

cpu_mitigations_off() and cpu_mitigations_auto_nosmt() could be
deprecated in favor of more vector-specific interfaces, and could be
removed once all the arches stop using them.  They could be gated by a
temporary ARCH_USES_MITIGATION_VECTORS option.  As could the per-vector
cmdline options.

Thoughts?

-- 
Josh