[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
