[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230814205300.krikym7jeckehqik@treble>
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
Powered by blists - more mailing lists