linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH 0/5] Introduce support for PSF mitigation
@ 2021-04-07 12:49 Ramakrishna Saripalli
  2021-04-07 14:01 ` Borislav Petkov
  0 siblings, 1 reply; 9+ messages in thread
From: Ramakrishna Saripalli @ 2021-04-07 12:49 UTC (permalink / raw)
  To: linux-kernel, x86, tglx, mingo, bp; +Cc: rsaripal

From: Ramakrishna Saripalli <rk.saripalli@amd.com>

Predictive Store Forwarding:
AMD Zen3 processors feature a new technology called
Predictive Store Forwarding (PSF).

https://www.amd.com/system/files/documents/security-analysis-predictive-store-forwarding.pdf

PSF is a hardware-based micro-architectural optimization designed
to improve the performance of code execution by predicting address
dependencies between loads and stores.

How PSF works:

It is very common for a CPU to execute a load instruction to an address
that was recently written by a store. Modern CPUs implement a technique
known as Store-To-Load-Forwarding (STLF) to improve performance in such
cases. With STLF, data from the store is forwarded directly to the load
without having to wait for it to be written to memory. In a typical CPU,
STLF occurs after the address of both the load and store are calculated
and determined to match.

PSF expands on this by speculating on the relationship between loads and
stores without waiting for the address calculation to complete. With PSF,
the CPU learns over time the relationship between loads and stores.
If STLF typically occurs between a particular store and load, the CPU will
remember this.

In typical code, PSF provides a performance benefit by speculating on
the load result and allowing later instructions to begin execution
sooner than they otherwise would be able to.

Causes of Incorrect PSF:

Incorrect PSF predictions can occur due to two reasons.

First, it is possible that the store/load pair had a dependency for a
while but later stops having a dependency.  This can occur if the address
of either the store or load changes during the execution of the program.

The second source of incorrect PSF predictions can occur if there is an
alias in the PSF predictor structure.  The PSF predictor tracks
store-load pairs based on portions of their RIP. It is possible that a
store-load pair which does have a dependency may alias in the predictor
with another store-load pair which does not.

This can result in incorrect speculation when the second store/load pair
is executed.

Security Analysis:

Previous research has shown that when CPUs speculate on non-architectural
paths it can lead to the potential of side channel attacks.
In particular, programs that implement isolation, also known as
‘sandboxing’, entirely in software may need to be concerned with incorrect
CPU speculation as they can occur due to bad PSF predictions.

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.

Support for PSFD is indicated in CPUID Fn8000_0008 EBX[28].
All processors that support PSF will also support PSFD.

Ramakrishna Saripalli (5):
  x86/cpufeatures: Define feature bits to support mitigation of PSF
  x86/speculation: Implement support for PSFD detection and reporting
  x86/speculation: Introduce SPEC_CTRL_MSR bit for PSFD
  x86/speculation: Implement PSF mitigation support
  x86/speculation: Add PSF mitigation kernel parameters

 .../admin-guide/kernel-parameters.txt         |  45 +++++
 arch/x86/include/asm/cpufeatures.h            |   4 +-
 arch/x86/include/asm/msr-index.h              |   2 +
 arch/x86/include/asm/nospec-branch.h          |   8 +
 arch/x86/include/asm/spec-ctrl.h              |  12 ++
 arch/x86/include/asm/thread_info.h            |   2 +
 arch/x86/kernel/cpu/bugs.c                    | 191 ++++++++++++++++++
 arch/x86/kernel/cpu/common.c                  |   6 +
 arch/x86/kernel/process.c                     |  23 +++
 include/linux/sched.h                         |  15 ++
 include/uapi/linux/prctl.h                    |   2 +
 11 files changed, 309 insertions(+), 1 deletion(-)


base-commit: 0e16f466004d7f04296b9676a712a32a12367d1f
-- 
2.25.1


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH 0/5] Introduce support for PSF mitigation
  2021-04-07 12:49 [PATCH 0/5] Introduce support for PSF mitigation Ramakrishna Saripalli
@ 2021-04-07 14:01 ` Borislav Petkov
  0 siblings, 0 replies; 9+ messages in thread
From: Borislav Petkov @ 2021-04-07 14:01 UTC (permalink / raw)
  To: Ramakrishna Saripalli; +Cc: linux-kernel, x86, tglx, mingo

On Wed, Apr 07, 2021 at 07:49:48AM -0500, Ramakrishna Saripalli wrote:
> From: Ramakrishna Saripalli <rk.saripalli@amd.com>

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH 0/5] Introduce support for PSF mitigation
  2021-04-09 16:45     ` Josh Poimboeuf
@ 2021-04-09 16:50       ` Saripalli, RK
  0 siblings, 0 replies; 9+ messages in thread
From: Saripalli, RK @ 2021-04-09 16:50 UTC (permalink / raw)
  To: Josh Poimboeuf; +Cc: linux-kernel, x86

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH 0/5] Introduce support for PSF mitigation
  2021-04-08 14:56   ` Saripalli, RK
  2021-04-09  9:07     ` Borislav Petkov
@ 2021-04-09 16:45     ` Josh Poimboeuf
  2021-04-09 16:50       ` Saripalli, RK
  1 sibling, 1 reply; 9+ messages in thread
From: Josh Poimboeuf @ 2021-04-09 16:45 UTC (permalink / raw)
  To: Saripalli, RK; +Cc: linux-kernel, x86

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


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH 0/5] Introduce support for PSF mitigation
  2021-04-08 14:56   ` Saripalli, RK
@ 2021-04-09  9:07     ` Borislav Petkov
  2021-04-09 16:45     ` Josh Poimboeuf
  1 sibling, 0 replies; 9+ messages in thread
From: Borislav Petkov @ 2021-04-09  9:07 UTC (permalink / raw)
  To: Saripalli, RK; +Cc: Josh Poimboeuf, linux-kernel, x86

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH 0/5] Introduce support for PSF mitigation
  2021-04-07 22:39 ` Josh Poimboeuf
@ 2021-04-08 14:56   ` Saripalli, RK
  2021-04-09  9:07     ` Borislav Petkov
  2021-04-09 16:45     ` Josh Poimboeuf
  0 siblings, 2 replies; 9+ messages in thread
From: Saripalli, RK @ 2021-04-08 14:56 UTC (permalink / raw)
  To: Josh Poimboeuf; +Cc: linux-kernel, x86

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH 0/5] Introduce support for PSF mitigation
  2021-04-06 15:49 Ramakrishna Saripalli
  2021-04-06 17:26 ` Borislav Petkov
@ 2021-04-07 22:39 ` Josh Poimboeuf
  2021-04-08 14:56   ` Saripalli, RK
  1 sibling, 1 reply; 9+ messages in thread
From: Josh Poimboeuf @ 2021-04-07 22:39 UTC (permalink / raw)
  To: Ramakrishna Saripalli; +Cc: linux-kernel, x86

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


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH 0/5] Introduce support for PSF mitigation
  2021-04-06 15:49 Ramakrishna Saripalli
@ 2021-04-06 17:26 ` Borislav Petkov
  2021-04-07 22:39 ` Josh Poimboeuf
  1 sibling, 0 replies; 9+ messages in thread
From: Borislav Petkov @ 2021-04-06 17:26 UTC (permalink / raw)
  To: Ramakrishna Saripalli; +Cc: linux-kernel, x86

On Tue, Apr 06, 2021 at 10:49:59AM -0500, Ramakrishna Saripalli wrote:
> From: Ramakrishna Saripalli <rk.saripalli@amd.com>
> 
> Predictive Store Forwarding:
> AMD Zen3 processors feature a new technology called
> Predictive Store Forwarding (PSF).
> 
> <TODO:Insert link to AMD PSF whitepaper>

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [PATCH 0/5] Introduce support for PSF mitigation
@ 2021-04-06 15:49 Ramakrishna Saripalli
  2021-04-06 17:26 ` Borislav Petkov
  2021-04-07 22:39 ` Josh Poimboeuf
  0 siblings, 2 replies; 9+ messages in thread
From: Ramakrishna Saripalli @ 2021-04-06 15:49 UTC (permalink / raw)
  To: linux-kernel, x86; +Cc: rsaripal

From: Ramakrishna Saripalli <rk.saripalli@amd.com>

Predictive Store Forwarding:
AMD Zen3 processors feature a new technology called
Predictive Store Forwarding (PSF).

<TODO:Insert link to AMD PSF whitepaper>

PSF is a hardware-based micro-architectural optimization designed
to improve the performance of code execution by predicting address
dependencies between loads and stores.

How PSF works:

It is very common for a CPU to execute a load instruction to an address
that was recently written by a store. Modern CPUs implement a technique
known as Store-To-Load-Forwarding (STLF) to improve performance in such
cases. With STLF, data from the store is forwarded directly to the load
without having to wait for it to be written to memory. In a typical CPU,
STLF occurs after the address of both the load and store are calculated
and determined to match.

PSF expands on this by speculating on the relationship between loads and
stores without waiting for the address calculation to complete. With PSF,
the CPU learns over time the relationship between loads and stores.
If STLF typically occurs between a particular store and load, the CPU will
remember this.

In typical code, PSF provides a performance benefit by speculating on
the load result and allowing later instructions to begin execution
sooner than they otherwise would be able to.

Causes of Incorrect PSF:

Incorrect PSF predictions can occur due to two reasons.

First, it is possible that the store/load pair had a dependency for a
while but later stops having a dependency.  This can occur if the address
of either the store or load changes during the execution of the program.

The second source of incorrect PSF predictions can occur if there is an
alias in the PSF predictor structure.  The PSF predictor tracks
store-load pairs based on portions of their RIP. It is possible that a
store-load pair which does have a dependency may alias in the predictor
with another store-load pair which does not.

This can result in incorrect speculation when the second store/load pair
is executed.

Security Analysis:

Previous research has shown that when CPUs speculate on non-architectural
paths it can lead to the potential of side channel attacks.
In particular, programs that implement isolation, also known as
‘sandboxing’, entirely in software may need to be concerned with incorrect
CPU speculation as they can occur due to bad PSF predictions.

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.

Support for PSFD is indicated in CPUID Fn8000_0008 EBX[28].
All processors that support PSF will also support PSFD.

Ramakrishna Saripalli (5):
  x86/cpufeatures: Define feature bits to support mitigation of PSF
  x86/speculation: Implement support for PSFD detection and reporting
  x86/speculation: Introduce SPEC_CTRL_MSR bit for PSFD
  x86/speculation: Implement PSF mitigation support
  x86/speculation: Add PSF mitigation kernel parameters

 .../admin-guide/kernel-parameters.txt         |  45 +++++
 arch/x86/include/asm/cpufeatures.h            |   4 +-
 arch/x86/include/asm/msr-index.h              |   2 +
 arch/x86/include/asm/nospec-branch.h          |   8 +
 arch/x86/include/asm/spec-ctrl.h              |  12 ++
 arch/x86/include/asm/thread_info.h            |   2 +
 arch/x86/kernel/cpu/bugs.c                    | 191 ++++++++++++++++++
 arch/x86/kernel/cpu/common.c                  |   6 +
 arch/x86/kernel/process.c                     |  23 +++
 include/linux/sched.h                         |  15 ++
 include/uapi/linux/prctl.h                    |   2 +
 11 files changed, 309 insertions(+), 1 deletion(-)


base-commit: 0e16f466004d7f04296b9676a712a32a12367d1f
-- 
2.25.1


^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2021-04-09 16:50 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-04-07 12:49 [PATCH 0/5] Introduce support for PSF mitigation Ramakrishna Saripalli
2021-04-07 14:01 ` Borislav Petkov
  -- strict thread matches above, loose matches on Subject: below --
2021-04-06 15:49 Ramakrishna Saripalli
2021-04-06 17:26 ` Borislav Petkov
2021-04-07 22:39 ` Josh Poimboeuf
2021-04-08 14:56   ` Saripalli, RK
2021-04-09  9:07     ` Borislav Petkov
2021-04-09 16:45     ` Josh Poimboeuf
2021-04-09 16:50       ` Saripalli, RK

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).