RE: [PATCH 1/6] x86/bugs: Create single parameter for VERW based mitigations

[Kaplan, David]

[AMD Official Use Only - AMD Internal Distribution Only]

> -----Original Message-----
> From: Daniel Sneddon <daniel.sneddon@xxxxxxxxxxxxxxx>
> Sent: Tuesday, September 24, 2024 5:32 PM
> To: Jonathan Corbet <corbet@xxxxxxx>; Thomas Gleixner <tglx@xxxxxxxxxxxxx>;
> Borislav Petkov <bp@xxxxxxxxx>; Peter Zijlstra <peterz@xxxxxxxxxxxxx>; Josh
> Poimboeuf <jpoimboe@xxxxxxxxxx>; Ingo Molnar <mingo@xxxxxxxxxx>; Dave
> Hansen <dave.hansen@xxxxxxxxxxxxxxx>; x86@xxxxxxxxxx
> Cc: hpa@xxxxxxxxx; linux-doc@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx;
> pawan.kumar.gupta@xxxxxxxxxxxxxxx
> Subject: [PATCH 1/6] x86/bugs: Create single parameter for VERW based
> mitigations
>
> There are currently 4 mitigations that use VERW to flush different cpu buffers. This
> can cause confusion when trying to disable all the different VERW mitigations.
> Simplify enabling/disabling these mitigations by creating a single parameter for
> controlling them.

Just curious, what is the use case for disabling the different VERW mitigations (but not other mitigations)?  Is that a testing/debugging use case or a production use case?

>
> Future work will focus on combining similar code used in selecting these mitigations
> to further simplify.
>
> Signed-off-by: Daniel Sneddon <daniel.sneddon@xxxxxxxxxxxxxxx>
> ---
>  .../admin-guide/kernel-parameters.txt         | 16 +++++++++
>  arch/x86/kernel/cpu/bugs.c                    | 34 +++++++++++++++++++
>  2 files changed, 50 insertions(+)
>
> diff --git a/Documentation/admin-guide/kernel-parameters.txt
> b/Documentation/admin-guide/kernel-parameters.txt
> index 09126bb8cc9f..66b567c4dce5 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -628,6 +628,21 @@
>       cio_ignore=     [S390]
>                       See Documentation/arch/s390/common_io.rst for details.
>
> +     clear_cpu_buffers=
> +                     [X86]
> +                     Controls the mitigations that use
> +                     X86_FEATURE_CLEAR_CPU_BUF, namely
> +                     Micro-architectrual Data Sampling (MDS)
> +                     MMIO Stale Data
> +                     TSX Async Abort (TAA)
> +                     Register File Data Sampling (RFDS)
> +
> +                     The options are:
> +                     on              - Enable cpu buffer clearing
> +                     on,nosmt        - Enable cpu buffer clearing and disable
> +                                       SMT
> +                     off             - Disables cpu buffer clearing
> +

At the x86 uconf at LPC, someone asked me about if we should have command line options that were mitigation-focused rather than bug-focused (like to enable STIBP, IBRS, etc.).  The feedback I had there applies to this series too, which is that I'm concerned this makes things more difficult for users because users are reacting to bugs, they're not experts in mitigations.  A user wants to know how to mitigate CVE XYZ, and the bug-specific command line options support that.  It's an extra step to say that to mitigate MDS, you have to figure out that MDS requires clearing cpu buffers, and therefore you should set this mitigation-specific option.

My general concern with this series is it seems to tie X86_FEATURE_CLEAR_CPU_BUF directly to these 4 bugs.  What would happen if hypothetically there was a new bug that required X86_FEATURE_CLEAR_CPU_BUF and some other mitigation?  With the existing bug-specific options this is easy enough, as the new bug could force this feature and do whatever else it needed.  But with a mitigation-specific option like this one, it would seem to be harder as it might require multiple options to mitigate one bug.  And could create conflicts if you enable that new mitigation but disable clear_cpu_buffers.

I do get the point that these specific 4 bugs are all closely related.  Another idea to consider could be a single command line option for these 4 bugs, but is tied to the bugs themselves, not the mitigation.  That might be more future-proof as the scope remains only about these 4 bugs, not the mitigation itself.

--David Kaplan