lkml.org 
[lkml]   [2021]   [Sep]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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

\
 
 \ /
  Last update: 2021-09-08 20:21    [W:0.149 / U:0.532 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site