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
| ||
|
Date: Thu, 09 Sep 2021 12:20:32 -0400 From: Bandan Das <bsd@...hat.com> To: Josh Poimboeuf <jpoimboe@...hat.com> Cc: "Moger, Babu" <bmoger@....com>, Babu Moger <babu.moger@....com>, bp@...en8.de, 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 Josh Poimboeuf <jpoimboe@...hat.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.
Powered by blists - more mailing lists