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: Wednesday, October 9, 2024 11:18 AM
> To: Kaplan, David <David.Kaplan@xxxxxxx>; 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: Re: [PATCH 1/6] x86/bugs: Create single parameter for VERW based
> mitigations
>
> Caution: This message originated from an External Source. Use proper
> caution when opening attachments, clicking links, or responding.
>
> >
> > 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.
> >
>
> Any new bug that is using X86_FEATURE_CLEAR_CPU_BUF will be related to
> these existing bugs regardless. We may need to add another option to this
> parameter, similar to what we do with ",nosmt", but I would hope that
> would be sufficient.
> With the existing bug-focused parameters we have the same potential for
> conflicts. What if I say "reg_file_data_sampling=off mds=full"? Since mds is
> on rfds will be on even though I requested it off. The intent of this parameter
> is to remove such conflicts.
>
> > 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.
> >
>
> Are you suggesting a name change away from "clear_cpu_buffers" since it is
> clearly about the mitigation rather than the bug? I'm not sure there is a good
> common name for those 4 bugs that isn't about the mitigation, but I'm open
> to any suggestions.
>

Yes, I think that would be better.  I wasn't sure on a name either.  In the RFDS webpage I see it described as "similar to data sampling transient execution attacks".  Perhaps something like that could be an umbrella term?

--David Kaplan