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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID:
 <LV3PR12MB9265A30309277CBB4A9B81D1947F2@LV3PR12MB9265.namprd12.prod.outlook.com>
Date: Wed, 9 Oct 2024 16:36:13 +0000
From: "Kaplan, David" <David.Kaplan@....com>
To: Daniel Sneddon <daniel.sneddon@...ux.intel.com>, Jonathan Corbet
	<corbet@....net>, Thomas Gleixner <tglx@...utronix.de>, Borislav Petkov
	<bp@...en8.de>, Peter Zijlstra <peterz@...radead.org>, Josh Poimboeuf
	<jpoimboe@...nel.org>, Ingo Molnar <mingo@...hat.com>, Dave Hansen
	<dave.hansen@...ux.intel.com>, "x86@...nel.org" <x86@...nel.org>
CC: "hpa@...or.com" <hpa@...or.com>, "linux-doc@...r.kernel.org"
	<linux-doc@...r.kernel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "pawan.kumar.gupta@...ux.intel.com"
	<pawan.kumar.gupta@...ux.intel.com>
Subject: RE: [PATCH 1/6] x86/bugs: Create single parameter for VERW based
 mitigations

[AMD Official Use Only - AMD Internal Distribution Only]

> -----Original Message-----
> From: Daniel Sneddon <daniel.sneddon@...ux.intel.com>
> Sent: Wednesday, October 9, 2024 11:18 AM
> To: Kaplan, David <David.Kaplan@....com>; Jonathan Corbet
> <corbet@....net>; Thomas Gleixner <tglx@...utronix.de>; Borislav Petkov
> <bp@...en8.de>; Peter Zijlstra <peterz@...radead.org>; Josh Poimboeuf
> <jpoimboe@...nel.org>; Ingo Molnar <mingo@...hat.com>; Dave Hansen
> <dave.hansen@...ux.intel.com>; x86@...nel.org
> Cc: hpa@...or.com; linux-doc@...r.kernel.org; linux-
> kernel@...r.kernel.org; pawan.kumar.gupta@...ux.intel.com
> 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