linux-kernel - RE: [PATCH v2 11/35] x86/bugs: Restructure spectre

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:
 <LV3PR12MB92653BF71C474E72CB2C81DB945B2@LV3PR12MB9265.namprd12.prod.outlook.com>
Date: Thu, 14 Nov 2024 16:45:37 +0000
From: "Kaplan, David" <David.Kaplan@....com>
To: Borislav Petkov <bp@...en8.de>
CC: Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>, Thomas Gleixner
	<tglx@...utronix.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>, "H . Peter
 Anvin" <hpa@...or.com>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v2 11/35] x86/bugs: Restructure spectre_v1 mitigation

[AMD Official Use Only - AMD Internal Distribution Only]

> -----Original Message-----
> From: Borislav Petkov <bp@...en8.de>
> Sent: Thursday, November 14, 2024 10:20 AM
> To: Kaplan, David <David.Kaplan@....com>
> Cc: Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>; Thomas Gleixner
> <tglx@...utronix.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; H . Peter Anvin
> <hpa@...or.com>; linux-kernel@...r.kernel.org
> Subject: Re: [PATCH v2 11/35] x86/bugs: Restructure spectre_v1 mitigation
>
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> On Thu, Nov 14, 2024 at 03:49:42PM +0000, Kaplan, David wrote:
> > Actually looks like the existing code wasn't always consistent here.
> > For srbds, ssb, and gds, it would still print a message about the
> > system being vulnerable even if mitigations=off was passed.  But for
> > the others it would not print a message.  I think I'm going to
> > suppress the message for all cases, but if people feel it should be the other way,
> let me know.
>
> Yeah, we probably should fix this in a pre-patch. I.e., if mitigations=off, not issue any
> "Vulnerable" message because this is the "master switch", so to speak.
>

I would prefer to fix it with these restructuring patches since they're moving around a lot of the code in this area anyway and putting these print messages in more consistent places.  Otherwise I have to do it twice...

> Or do we want to issue a bunch of "Vulnerable" in dmesg?
>
> I gravitate towards former because if user supplies mitigations=off, then she
> probably knows what she's doing...?
>
> Hmm.
>

Right, there are 4 cases I think:
1) the CPU is not vulnerable (it doesn't have the bug)
2) the CPU is vulnerable but mitigations=off was passed
3) the CPU is vulnerable but the bug-specific mitigation was disabled (e.g., retbleed=off)
4) the CPU is vulnerable, mitigations were not disabled, but no mitigation is available (perhaps it wasn't compiled in)

We absolutely should not print a message in case #1, because the CPU isn't vulnerable.  And we should probably always print a message in case 4 to warn the user.  Question is really about cases 2 and 3.

Today, some bugs print a message saying the CPU is vulnerable in case 2 and 3 (e.g., gds)
Some bugs don't print a message in case 2, but do in case 3 (e.g., spectre_v1)
Some don't print a message in case 2 or 3 (e.g., retbleed)

Case 4 is things like where you need SRSO mitigation but CONFIG_MITIGATION_SRSO was disabled.

So which do we want?  It would be nice to be consistent and I can do that while reworking these functions.

If we're going to argue that command line options mean the user knows what they're doing, that's probably an argument for saying do not print anything in cases 2 and 3 (since both relate to explicit command line options).  I'm not sure if it really makes sense to differentiate these cases.

Thoughts?

--David Kaplan