Re: [v6 1/1] x86/bugs: Implement mitigation for Predictive Store

[Bandan Das <bsd@redhat.com>]

Josh Poimboeuf <jpoimboe@redhat.com> writes:

> On Fri, Sep 03, 2021 at 07:52:43PM -0500, Moger, Babu wrote:
>> > BTW, is the list of PSF-affected CPUs the same as the list of
>> > SSB-affected CPUs?  If there might be PSF CPUs which don't have SSB,
>> > then more logic will need to be added to ensure a sensible default.
>> I can't think of a scenario where it is not same on a system.
>
> To clarify, I'm asking about CPU capabilities.  Are there any AMD CPUs
> with the PSF feature, which don't have SSB?
>
>> > On a related note, is there a realistic, non-hypothetical need to have
>> > separate policies and cmdline options for both SSB and PSF?  i.e. is
>> > there a real-world scenario where a user needs to disable PSF while
>> > leaving SSB enabled?
>> 
>> https://www.amd.com/system/files/documents/security-analysis-predictive-store-forwarding.pdf <https://www.amd.com/system/files/documents/security-analysis-predictive-store-forwarding.pdf>
>> There are some examples in the document. Probably it is too soon to tell if
>> those are real real-world scenarios as this feature is very new.
>
> I didn't see any actual examples.  Are you referring to this sentence?
>
>   "PSFD may be desirable for software which is concerned with the
>    speculative behavior of PSF but desires a smaller performance impact
>    than setting SSBD."
>
Sounds reasonable. It would have been good if the whitepaper mentioned
any real examples which could benefit from selectively disabling psf.
Generally speaking, as a user, I would either want to turn speculation
entirely off or on which is what ssbd already does.

>> > 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.