Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Wed, 8 Sep 2021 11:20:47 -0700
From:   Josh Poimboeuf <jpoimboe@redhat.com>
To:     Babu Moger <babu.moger@amd.com>
Cc:     "Moger, Babu" <bmoger@amd.com>, bp@alien8.de, bsd@redhat.com,
        corbet@lwn.net, hpa@zytor.com, linux-kernel@vger.kernel.org,
        mingo@redhat.com, tglx@linutronix.de, x86@kernel.org
Subject: Re: [v6 1/1] x86/bugs: Implement mitigation for Predictive Store
Message-ID: <20210908182047.lcor52bjzrt35gsq@treble>
References: <20210812234440.tcssf2iqs435bgdo@treble>
 <20210902181637.244879-1-babu.moger@amd.com>
 <20210903000706.fb43tzhjanyg64cx@treble>
 <dca004cf-bacc-1a1f-56d6-c06e8bec167a@amd.com>
 <20210904172334.lfjyqi4qfzvbxef7@treble>
 <35a32225-25d3-88eb-f427-14c93c38c97b@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <35a32225-25d3-88eb-f427-14c93c38c97b@amd.com>
Precedence: bulk

On Tue, Sep 07, 2021 at 06:15:53PM -0500, Babu Moger wrote:
> >>> Because trying to give them separate interfaces, when PSF disable is
> >>> intertwined with SSB disable in hardware, is awkward and confusing.  And
> >>> the idea of adding another double-negative interface (disable=off!),
> >>> just because a vulnerability is considered to be a CPU "feature", isn't
> >>> very appetizing.
> >>>
> >>> So instead of adding a new double-negative interface, which only *half*
> >>> works due to the ssb_disable dependency, and which is guaranteed to
> >>> further confuse users, and which not even be used in the real world
> >>> except possibly by confused users...
> >>>
> >>> I'm wondering if we can just start out with the simplest possible
> >>> approach: don't change any code and instead just document the fact that
> >>> "spec_store_bypass_disable=" also affects PSF.
> >>>
> >>> Then, later on, if a real-world need is demonstrated, actual code could
> >>> be added to support disabling PSF independently (but of course it would
> >>> never be fully independent since PSF disable is forced by SSB disable).
> >>
> >> Do you mean for now keep only 'on' and  'auto' and remove "off"?
> > 
> > No, since PSF can already be mitigated with SSBD today, I'm suggesting
> > that all code be removed from the patch and instead just update the
> > documentation.
> > 
> 
> Hmm Interesting..
> Just updating the documentation and without giving interface to enable or
> disable will not be a much of a value add.

It's also not a value add to create controls and added complexity for a
feature which nobody needs.  There's no harm in starting out with the
simplest possible solution, which is no code at all.

Code can always be added later if really needed...

-- 
Josh