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:   Tue, 15 Aug 2023 14:27:51 -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: Correct the mitigation status when SMT is
 disabled
Message-ID: <20230815212751.xhsyn7iwj2gwpuk5@treble>
References: <20230813104517.3346-1-bp@alien8.de>
 <1588ed00-be11-ff9d-e4c2-12db78cca06f@suse.com>
 <20230814200813.p5czl47zssuej7nv@treble>
 <20230814202545.GKZNqNybUnKv+xyrtP@fat_crate.local>
 <20230814205300.krikym7jeckehqik@treble>
 <20230814211727.GLZNqZ5+flxtyaDjMQ@fat_crate.local>
 <20230815095724.GBZNtMBPUJSEegviJN@fat_crate.local>
 <20230815195831.2opbgrznnpszaa32@treble>
 <20230815201753.GGZNvdcbPHXtEXn4As@fat_crate.local>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20230815201753.GGZNvdcbPHXtEXn4As@fat_crate.local>
Precedence: bulk

On Tue, Aug 15, 2023 at 10:17:53PM +0200, Borislav Petkov wrote:
> On Tue, Aug 15, 2023 at 12:58:31PM -0700, Josh Poimboeuf wrote:
> > AFAICT, nowhere in the spec does it say the SRSO_NO bit won't get set by
> > future (fixed) HW.  In fact I'd expect it will, similar to other *_NO
> > flags.
> 
> I'm pretty sure it won't.
> 
> SRSO_NO is synthesized by the hypervisor *software*. Nothing else.

Citation needed.

> It is there so that you don't check microcode version in the guest which
> is nearly impossible anyway.
> 
> > Regardless, here SRSO_NO seems to mean two different things: "reported
> > safe by host (or HW)" and "not reported safe on Zen1/2 with SMT not
> > possible".
> 
> Huh?

Can you clarify what doesn't make sense?

> > Also, in this code, the SRSO_NO+SMT combo doesn't seem logically
> > possible, as srso_show_state() only gets called if X86_BUG_SRSO is set,
> > which only happens if SRSO_NO is not set by the HW/host in the first
> > place.  So here, if boot_cpu_has(X86_FEATURE_SRSO_NO), it means SRSO_NO
> > was manually set by srso_select_mitigation(), and SMT can't possibly be
> > enabled.
> 
> Have you considered the case where Linux would set SRSO_NO when booting
> on future hardware, which is fixed?
> 
> There SRSO_NO and SMT will very much be possible.

How is that relevant to my comment?  The bug bit still wouldn't get set
and srso_show_state() still wouldn't be called.

-- 
Josh