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 for Android: free password hash cracker in your pocket

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

Message-ID: <9ed4ce15-68b8-4604-bbe1-34fb8ca1f9eb@linux.intel.com>
Date: Tue, 15 Oct 2024 07:05:58 -0700
From: Daniel Sneddon <daniel.sneddon@...ux.intel.com>
To: Borislav Petkov <bp@...en8.de>
Cc: Josh Poimboeuf <jpoimboe@...nel.org>, "Kaplan, David"
 <David.Kaplan@....com>, Jonathan Corbet <corbet@....net>,
 Thomas Gleixner <tglx@...utronix.de>, Peter Zijlstra <peterz@...radead.org>,
 Ingo Molnar <mingo@...hat.com>, Dave Hansen <dave.hansen@...ux.intel.com>,
 "x86@...nel.org" <x86@...nel.org>, "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

On 10/15/24 06:52, Borislav Petkov wrote:
> On Mon, Oct 14, 2024 at 08:42:26AM -0700, Daniel Sneddon wrote:
>> The reason I did the patches this way wasn't so much "need" as it just seemed a
>> simpler way to do it. Why have 4 knobs when there is really only 1 mitigation
>> under the hood? My question for you then is what you mean by "proper sync"? I'm
>> guessing you mean that if any one of those 4 mitigations is set to off then
>> assume all are off? 
> 
> Well, up until now at least, we have handled under the assumption that not
> every user knows exactly what needs to be configured in order to be safe.
> 
> So, we have always aimed for a sane default.
> 
> IOW, if a user wants to disable one mitigation but all 4 are mitigated by the
> same thing, then we probably should issue a warning saying something like:
> 
> 	"If you want to disable W, then you need to disable W, X and Y too in
> 	order to disable W effectively as all 4 are mitigated by the same
> 	mechanism."
> 
> And problem solved.

Makes sense. I'll drop the new parameter and add a warning.

Thanks,
Dan
> 
> IOW, I don't expect someone would consciously want to disable a subset of
> those mitigations but leave the remaining ones on. What usually happens, is
> people do "mitigations=off" in order to regain their performance but not do
> this selective thing which doesn't make a whole lot sense to me anyway.
> 
> Thx.
>