Messages in this thread | | | Date | Wed, 8 Sep 2021 11:20:47 -0700 | From | Josh Poimboeuf <> | Subject | Re: [v6 1/1] x86/bugs: Implement mitigation for Predictive Store |
| |
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
| |