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

Josh Poimboeuf
2025-02-17T20:19:12Z

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