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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Fri, 10 Sep 2021 11:08:01 -0500
From:   Babu Moger <babu.moger@....com>
To:     Josh Poimboeuf <jpoimboe@...hat.com>
Cc:     "Moger, Babu" <bmoger@....com>, bp@...en8.de, bsd@...hat.com,
        corbet@....net, hpa@...or.com, linux-kernel@...r.kernel.org,
        mingo@...hat.com, tglx@...utronix.de, x86@...nel.org
Subject: Re: [v6 1/1] x86/bugs: Implement mitigation for Predictive Store



On 9/8/21 1:20 PM, Josh Poimboeuf wrote:
> 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...
> 
Alright. Lets revisit this later when it seems reasonable to add this in
the kernel.

For now, I will focus on exposing this feature in KVM where guests can
make use of it. It appears straight forward. Will send those patches soon.
thanks
Babu