Re: [PATCH 0/5] Introduce support for PSF mitigation
Josh, PSF being new, may be in the future someone will find something new. This is really extra precaution. On 4/9/2021 11:45 AM, Josh Poimboeuf wrote: > On Thu, Apr 08, 2021 at 09:56:47AM -0500, Saripalli, RK wrote: >> Josh, thank you for taking the time to review the patches. >> >> On 4/7/2021 5:39 PM, Josh Poimboeuf wrote: >>> On Tue, Apr 06, 2021 at 10:49:59AM -0500, Ramakrishna Saripalli wrote: Because PSF speculation is limited to the current program context, the impact of bad PSF speculation is very similar to that of Speculative Store Bypass (Spectre v4) Predictive Store Forwarding controls: There are two hardware control bits which influence the PSF feature: - MSR 48h bit 2 – Speculative Store Bypass (SSBD) - MSR 48h bit 7 – Predictive Store Forwarding Disable (PSFD) The PSF feature is disabled if either of these bits are set. These bits are controllable on a per-thread basis in an SMT system. By default, both SSBD and PSFD are 0 meaning that the speculation features are enabled. While the SSBD bit disables PSF and speculative store bypass, PSFD only disables PSF. PSFD may be desirable for software which is concerned with the speculative behavior of PSF but desires a smaller performance impact than setting SSBD. >>> >>> Hi Ramakrishna, >>> >>> Is there a realistic scenario where an application would want to disable >>> PSF, but not disable SSB? >> >> It is possible most applications have been reviewed and scrubbed for >> SSB-type attacks but PSF-type issues may not have been looked at yet. > > It's "possible", but is it realistic? As far as I know, SSB is > impractical to scrub an application for. > > Do we know of any real-world cases where this option is needed? >
Re: [PATCH 0/5] Introduce support for PSF mitigation
On Thu, Apr 08, 2021 at 09:56:47AM -0500, Saripalli, RK wrote: > Josh, thank you for taking the time to review the patches. > > On 4/7/2021 5:39 PM, Josh Poimboeuf wrote: > > On Tue, Apr 06, 2021 at 10:49:59AM -0500, Ramakrishna Saripalli wrote: > >> Because PSF speculation is limited to the current program context, > >> the impact of bad PSF speculation is very similar to that of > >> Speculative Store Bypass (Spectre v4) > >> > >> Predictive Store Forwarding controls: > >> There are two hardware control bits which influence the PSF feature: > >> - MSR 48h bit 2 – Speculative Store Bypass (SSBD) > >> - MSR 48h bit 7 – Predictive Store Forwarding Disable (PSFD) > >> > >> The PSF feature is disabled if either of these bits are set. These bits > >> are controllable on a per-thread basis in an SMT system. By default, both > >> SSBD and PSFD are 0 meaning that the speculation features are enabled. > >> > >> While the SSBD bit disables PSF and speculative store bypass, PSFD only > >> disables PSF. > >> > >> PSFD may be desirable for software which is concerned with the > >> speculative behavior of PSF but desires a smaller performance impact than > >> setting SSBD. > > > > Hi Ramakrishna, > > > > Is there a realistic scenario where an application would want to disable > > PSF, but not disable SSB? > > It is possible most applications have been reviewed and scrubbed for > SSB-type attacks but PSF-type issues may not have been looked at yet. It's "possible", but is it realistic? As far as I know, SSB is impractical to scrub an application for. Do we know of any real-world cases where this option is needed? -- Josh
Re: [PATCH 0/5] Introduce support for PSF mitigation
On Thu, Apr 08, 2021 at 09:56:47AM -0500, Saripalli, RK wrote: > It is possible most applications have been reviewed and scrubbed for > SSB-type attacks but PSF-type issues may not have been looked at yet. > This may be one of the cases where SSB is enabled but PSF is disabled > until the application(s) are scrubbed for the same. Right, and for that I think we could do a slimmer version of the psfd= toggle - no prctl and seccomp stuff - just the cmdline disable thing to keep this simpler. Btw "psfd=" is maybe too short and cryptic. It would probably be more user-friendly if it were called: predict_store_fwd={on,off,...} or so. Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette
Re: [PATCH 0/5] Introduce support for PSF mitigation
Josh, thank you for taking the time to review the patches. On 4/7/2021 5:39 PM, Josh Poimboeuf wrote: > On Tue, Apr 06, 2021 at 10:49:59AM -0500, Ramakrishna Saripalli wrote: >> Because PSF speculation is limited to the current program context, >> the impact of bad PSF speculation is very similar to that of >> Speculative Store Bypass (Spectre v4) >> >> Predictive Store Forwarding controls: >> There are two hardware control bits which influence the PSF feature: >> - MSR 48h bit 2 – Speculative Store Bypass (SSBD) >> - MSR 48h bit 7 – Predictive Store Forwarding Disable (PSFD) >> >> The PSF feature is disabled if either of these bits are set. These bits >> are controllable on a per-thread basis in an SMT system. By default, both >> SSBD and PSFD are 0 meaning that the speculation features are enabled. >> >> While the SSBD bit disables PSF and speculative store bypass, PSFD only >> disables PSF. >> >> PSFD may be desirable for software which is concerned with the >> speculative behavior of PSF but desires a smaller performance impact than >> setting SSBD. > > Hi Ramakrishna, > > Is there a realistic scenario where an application would want to disable > PSF, but not disable SSB? It is possible most applications have been reviewed and scrubbed for SSB-type attacks but PSF-type issues may not have been looked at yet. This may be one of the cases where SSB is enabled but PSF is disabled until the application(s) are scrubbed for the same. In certain cases, disabling PSF may have less impact performance-wise than disabling SSB. > > Maybe I'm missing something, but I'd presume an application would either > care about this class of attacks, or not. >
Re: [PATCH 0/5] Introduce support for PSF mitigation
On Tue, Apr 06, 2021 at 10:49:59AM -0500, Ramakrishna Saripalli wrote: > Because PSF speculation is limited to the current program context, > the impact of bad PSF speculation is very similar to that of > Speculative Store Bypass (Spectre v4) > > Predictive Store Forwarding controls: > There are two hardware control bits which influence the PSF feature: > - MSR 48h bit 2 – Speculative Store Bypass (SSBD) > - MSR 48h bit 7 – Predictive Store Forwarding Disable (PSFD) > > The PSF feature is disabled if either of these bits are set. These bits > are controllable on a per-thread basis in an SMT system. By default, both > SSBD and PSFD are 0 meaning that the speculation features are enabled. > > While the SSBD bit disables PSF and speculative store bypass, PSFD only > disables PSF. > > PSFD may be desirable for software which is concerned with the > speculative behavior of PSF but desires a smaller performance impact than > setting SSBD. Hi Ramakrishna, Is there a realistic scenario where an application would want to disable PSF, but not disable SSB? Maybe I'm missing something, but I'd presume an application would either care about this class of attacks, or not. -- Josh
Re: [PATCH 0/5] Introduce support for PSF mitigation
On Wed, Apr 07, 2021 at 07:49:48AM -0500, Ramakrishna Saripalli wrote: > From: Ramakrishna Saripalli It seems you're new to this kernel development thing. While you're waiting for your patches to be reviewed fully and properly, please take the time to read Documentation/process/submitting-patches.rst and all the others in Documentation/process/ which explains how this whole game works. For example: "Once upon a time, patches used to disappear into the void without comment, but the development process works more smoothly than that now. You should receive comments within a week or so; if that does not happen, make sure that you have sent your patches to the right place. Wait for a minimum of one week before resubmitting or pinging reviewers ^^ - possibly longer during busy times like merge windows." Feel free to ask questions if something's unclear. Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette
Re: [PATCH 0/5] Introduce support for PSF mitigation
On Tue, Apr 06, 2021 at 10:49:59AM -0500, Ramakrishna Saripalli wrote: > From: Ramakrishna Saripalli > > Predictive Store Forwarding: > AMD Zen3 processors feature a new technology called > Predictive Store Forwarding (PSF). > > You probably should upload it here: https://bugzilla.kernel.org/show_bug.cgi?id=206537 instead and then point to it in the docs. And by "docs" I mean, putting all that nice text below which I've snipped in here: Documentation/admin-guide/hw-vuln/ for future reference. Look at the docs there for an idea how to structure it. I have come to appreciate our documentation a lot these days when I've forgotten all about those nightmares but needed to refresh them back in my L1. Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette