linux-kernel - Re: [PATCH] x86/srso: Disable the mitigation on unaffected configurations

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]

Date:   Mon, 14 Aug 2023 13:53:00 -0700
From:   Josh Poimboeuf <jpoimboe@...nel.org>
To:     Borislav Petkov <bp@...en8.de>
Cc:     Nikolay Borisov <nik.borisov@...e.com>, X86 ML <x86@...nel.org>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] x86/srso: Disable the mitigation on unaffected
 configurations

On Mon, Aug 14, 2023 at 10:25:45PM +0200, Borislav Petkov wrote:
> On Mon, Aug 14, 2023 at 01:08:13PM -0700, Josh Poimboeuf wrote:
> > Tangentially, the 'cpu_smt_control == CPU_SMT_DISABLED' check is wrong,
> > as SMT could still get enabled at runtime and SRSO would be exposed.
> 
> Well, even if it gets exposed, I don't think we can safely enable the
> mitigation at runtime as alternatives have run already.

Right, I wasn't suggesting to enable the mitigation at runtime.  Rather,
enable the mitigation at boot time, if SMT is even possible.  That's
what we've done for other mitigations.  Better safe than sorry.

> I guess I could use CPU_SMT_FORCE_DISABLED here.

cpu_smt_possible() already does that.

> > Also is there a reason to re-use the hardware SRSO_NO bit
> 
> Not a hardware bit - this is set by software - it is only allocated in
> the CPUID leaf for easier interaction with guests.

2. ENUMERATION OF NEW CAPABILITIES
AMD is defining three new CPUID bits to assist with the enumeration of capabilities related to SRSO:
CPUID Fn8000_0021_EAX[29] (SRSO_NO) – If this bit is 1, it indicates the CPU is not subject to the SRSO
vulnerability.
CPUID Fn8000_0021_EAX[28] (IBPB_BRTYPE) – If this bit is 1, it indicates that MSR 49h (PRED_CMD) bit 0
(IBPB) flushes all branch type predictions from the CPU branch predictor.
CPUID Fn8000_0021_EAX[27] (SBPB)

> > rather than clear the bug bit? 
> 
> We don't clear the X86_BUGs. Ever. The logic is that if the CPU matches
> an affected CPU, that flag remains to show that it is potentially
> affected.

Hm, ok.  I thought that was the point of the vulnerabilities file.

> /sys/devices/system/cpu/vulnerabilities/ tells you what the actual state
> is.

Since technically the CPU is affected, I'm thinking it should say
"Mitigation: SMT disabled" or such, instead of "Not affected".

> > That seems cleaner, then you wouldn't need this hack:
> 
> Not a hack. This is just like the other "not affected" feature flags.

Hm?  You mean the *_NO ones that determine whether the BUG bits get set
in the first place?  How do they print "Not affected"?

-- 
Josh