Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Mon, 14 Aug 2023 13:53:00 -0700
From:   Josh Poimboeuf <jpoimboe@kernel.org>
To:     Borislav Petkov <bp@alien8.de>
Cc:     Nikolay Borisov <nik.borisov@suse.com>, X86 ML <x86@kernel.org>,
        Josh Poimboeuf <jpoimboe@redhat.com>,
        LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] x86/srso: Disable the mitigation on unaffected
 configurations
Message-ID: <20230814205300.krikym7jeckehqik@treble>
References: <20230813104517.3346-1-bp@alien8.de>
 <1588ed00-be11-ff9d-e4c2-12db78cca06f@suse.com>
 <20230814200813.p5czl47zssuej7nv@treble>
 <20230814202545.GKZNqNybUnKv+xyrtP@fat_crate.local>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20230814202545.GKZNqNybUnKv+xyrtP@fat_crate.local>
Precedence: bulk

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