From: Ramakrishna Saripalli <[email protected]>
Certain AMD processors feature a new technology called Predictive Store
Forwarding (PSF).
PSF is a micro-architectural optimization designed to improve the
performance of code execution by predicting dependencies between
loads and stores.
Incorrect PSF predictions can occur due to two reasons.
- It is possible that the load/store pair may have had dependency for
a while but the dependency has stopped because the address in the
load/store pair has changed.
- Second source of incorrect PSF prediction can occur because of an alias
in the PSF predictor structure stored in the microarchitectural state.
PSF predictor tracks load/store pair based on portions of instruction
pointer. It is possible that a load/store pair which does have a
dependency may be aliased by another load/store pair which does not have
the same dependency. This can result in incorrect speculation.
Software may be able to detect this aliasing and perform side-channel
attacks.
All CPUs that implement PSF provide one bit to disable this feature.
If the bit to disable this feature is available, it means that the CPU
implements PSF feature and is therefore vulnerable to PSF risks.
The bits that are introduced
X86_FEATURE_PSFD: CPUID_Fn80000008_EBX[28] ("PSF disable")
If this bit is 1, CPU implements PSF and PSF control
via SPEC_CTRL_MSR is supported in the CPU.
All AMD processors that support PSF implement a bit in
SPEC_CTRL MSR (0x48) to disable or enable Predictive Store
Forwarding.
PSF control introduces a new kernel parameter called
predict_store_fwd.
Kernel parameter predict_store_fwd has the following values
- off. This value is used to disable PSF on all CPUs.
- on. This value is used to enable PSF on all CPUs.
This is also the default setting.
Signed-off-by: Ramakrishna Saripalli<[email protected]>
---
.../admin-guide/kernel-parameters.txt | 5 +++++
arch/x86/include/asm/cpufeatures.h | 1 +
arch/x86/include/asm/msr-index.h | 2 ++
arch/x86/kernel/cpu/amd.c | 19 +++++++++++++++++++
arch/x86/kernel/cpu/bugs.c | 6 +++++-
5 files changed, 32 insertions(+), 1 deletion(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 04545725f187..a4dd08bb0d3a 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -3940,6 +3940,11 @@
Format: {"off"}
Disable Hardware Transactional Memory
+ predict_store_fwd= [X86] This option controls PSF.
+ off - Turns off PSF.
+ on - Turns on PSF.
+ default : on.
+
preempt= [KNL]
Select preemption mode if you have CONFIG_PREEMPT_DYNAMIC
none - Limited to cond_resched() calls
diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h
index cc96e26d69f7..078f46022293 100644
--- a/arch/x86/include/asm/cpufeatures.h
+++ b/arch/x86/include/asm/cpufeatures.h
@@ -309,6 +309,7 @@
#define X86_FEATURE_AMD_SSBD (13*32+24) /* "" Speculative Store Bypass Disable */
#define X86_FEATURE_VIRT_SSBD (13*32+25) /* Virtualized Speculative Store Bypass Disable */
#define X86_FEATURE_AMD_SSB_NO (13*32+26) /* "" Speculative Store Bypass is fixed in hardware. */
+#define X86_FEATURE_PSFD (13*32+28) /* Predictive Store Forward Disable */
/* Thermal and Power Management Leaf, CPUID level 0x00000006 (EAX), word 14 */
#define X86_FEATURE_DTHERM (14*32+ 0) /* Digital Thermal Sensor */
diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
index 546d6ecf0a35..f569918c8754 100644
--- a/arch/x86/include/asm/msr-index.h
+++ b/arch/x86/include/asm/msr-index.h
@@ -51,6 +51,8 @@
#define SPEC_CTRL_STIBP BIT(SPEC_CTRL_STIBP_SHIFT) /* STIBP mask */
#define SPEC_CTRL_SSBD_SHIFT 2 /* Speculative Store Bypass Disable bit */
#define SPEC_CTRL_SSBD BIT(SPEC_CTRL_SSBD_SHIFT) /* Speculative Store Bypass Disable */
+#define SPEC_CTRL_PSFD_SHIFT 7
+#define SPEC_CTRL_PSFD BIT(SPEC_CTRL_PSFD_SHIFT) /* Predictive Store Forwarding Disable */
#define MSR_IA32_PRED_CMD 0x00000049 /* Prediction Command */
#define PRED_CMD_IBPB BIT(0) /* Indirect Branch Prediction Barrier */
diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index 347a956f71ca..2ae74b68c6d3 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -1170,3 +1170,22 @@ void set_dr_addr_mask(unsigned long mask, int dr)
break;
}
}
+
+static int __init psf_cmdline(char *str)
+{
+ if (!boot_cpu_has(X86_FEATURE_PSFD))
+ return 0;
+
+ if (!str)
+ return -EINVAL;
+
+ if (!strcmp(str, "off")) {
+ set_cpu_cap(&boot_cpu_data, X86_FEATURE_MSR_SPEC_CTRL);
+ x86_spec_ctrl_base |= SPEC_CTRL_PSFD;
+ msr_set_bit(MSR_IA32_SPEC_CTRL, SPEC_CTRL_PSFD_SHIFT);
+ }
+
+ return 0;
+}
+
+early_param("predict_store_fwd", psf_cmdline);
diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index d41b70fe4918..536136e0daa3 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -78,6 +78,8 @@ EXPORT_SYMBOL_GPL(mds_idle_clear);
void __init check_bugs(void)
{
+ u64 tmp = 0;
+
identify_boot_cpu();
/*
@@ -97,7 +99,9 @@ void __init check_bugs(void)
* init code as it is not enumerated and depends on the family.
*/
if (boot_cpu_has(X86_FEATURE_MSR_SPEC_CTRL))
- rdmsrl(MSR_IA32_SPEC_CTRL, x86_spec_ctrl_base);
+ rdmsrl(MSR_IA32_SPEC_CTRL, tmp);
+
+ x86_spec_ctrl_base |= tmp;
/* Allow STIBP in MSR_SPEC_CTRL if supported */
if (boot_cpu_has(X86_FEATURE_STIBP))
--
2.25.1
On Wed, May 05 2021 at 14:09, Ramakrishna Saripalli wrote:
> From: Ramakrishna Saripalli <[email protected]>
>
> Certain AMD processors feature a new technology called Predictive Store
> Forwarding (PSF).
>
> PSF is a micro-architectural optimization designed to improve the
> performance of code execution by predicting dependencies between
> loads and stores.
>
> Incorrect PSF predictions can occur due to two reasons.
>
> - It is possible that the load/store pair may have had dependency for
> a while but the dependency has stopped because the address in the
> load/store pair has changed.
>
> - Second source of incorrect PSF prediction can occur because of an alias
> in the PSF predictor structure stored in the microarchitectural state.
> PSF predictor tracks load/store pair based on portions of instruction
> pointer. It is possible that a load/store pair which does have a
> dependency may be aliased by another load/store pair which does not have
> the same dependency. This can result in incorrect speculation.
>
> Software may be able to detect this aliasing and perform side-channel
> attacks.
So this is the new post spectre/meltdown/.../ world order.
What would have been considered a potential speculative side channel bug
two years ago is now sold a feature which is by default enabled.
Just to be clear. From a security POV this is just yet another
default enabled speculative vulnerability. The difference to the others
is that this is communicated upfront and comes with a knob to turn it
off right away.
There is also interaction with SSB and the SSB mitigation which is
described in the cover letter, but not in the changelog and is not
detectable from user space.
I know that you had it implemented that way in your first attempt, but I
was busy with other things and missed the discussion which resulted in
this being treated as a feature.
TBH, I'm not really happy about this because that's inconsistent with
how we treat the other speculation related issues and there is no way
for user space to actually check this like the other one via /sys/....
> +++ b/arch/x86/kernel/cpu/amd.c
> @@ -1170,3 +1170,22 @@ void set_dr_addr_mask(unsigned long mask, int dr)
> break;
> }
> }
> +
> +static int __init psf_cmdline(char *str)
> +{
> + if (!boot_cpu_has(X86_FEATURE_PSFD))
> + return 0;
> +
> + if (!str)
> + return -EINVAL;
> +
> + if (!strcmp(str, "off")) {
> + set_cpu_cap(&boot_cpu_data, X86_FEATURE_MSR_SPEC_CTRL);
What? Why is this setting this feature here and why is this not done in
init_speculation_control() as for all the other speculation misfeatures?
> + x86_spec_ctrl_base |= SPEC_CTRL_PSFD;
What? See below.
> + msr_set_bit(MSR_IA32_SPEC_CTRL, SPEC_CTRL_PSFD_SHIFT);
> + }
> +
> + return 0;
So any parameter is treated as valid here. That's interesting at best.
> --- a/arch/x86/kernel/cpu/bugs.c
> +++ b/arch/x86/kernel/cpu/bugs.c
> @@ -78,6 +78,8 @@ EXPORT_SYMBOL_GPL(mds_idle_clear);
>
> void __init check_bugs(void)
> {
> + u64 tmp = 0;
> +
> identify_boot_cpu();
>
> /*
> @@ -97,7 +99,9 @@ void __init check_bugs(void)
> * init code as it is not enumerated and depends on the family.
> */
> if (boot_cpu_has(X86_FEATURE_MSR_SPEC_CTRL))
> - rdmsrl(MSR_IA32_SPEC_CTRL, x86_spec_ctrl_base);
> + rdmsrl(MSR_IA32_SPEC_CTRL, tmp);
> +
> + x86_spec_ctrl_base |= tmp;
How is anyone supposed to understand that logic?
Just because x86_spec_ctrl_base is a global variable does not justify
this hackery at all. It's just a matter of time that someone reads this:
u64 x86_spec_ctrl_base;
void __init check_bugs(void)
{
u64 tmp = 0;
...
if (boot_cpu_has(X86_FEATURE_MSR_SPEC_CTRL))
rdmsrl(MSR_IA32_SPEC_CTRL, tmp);
x86_spec_ctrl_base |= tmp;
and figures that this is a pointless exercise and reverts that hunk.
What's wrong with just treating this in the same way in which we treat
all other speculative vulnerabilities and provide a consistent picture
to the user?
Something like the below. You get the idea.
Thanks,
tglx
---
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -111,6 +111,7 @@ void __init check_bugs(void)
mds_select_mitigation();
taa_select_mitigation();
srbds_select_mitigation();
+ psf_select_mitigation();
/*
* As MDS and TAA mitigations are inter-related, print MDS
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -891,6 +891,9 @@ static void init_speculation_control(str
set_cpu_cap(c, X86_FEATURE_MSR_SPEC_CTRL);
clear_cpu_cap(c, X86_FEATURE_VIRT_SSBD);
}
+
+ if (!boot_cpu_has(X86_FEATURE_PSFD))
+ set_cpu_cap(c, X86_FEATURE_MSR_SPEC_CTRL);
}
void get_cpu_cap(struct cpuinfo_x86 *c)
On 5/7/2021 10:13 AM, Thomas Gleixner wrote:
> On Wed, May 05 2021 at 14:09, Ramakrishna Saripalli wrote:
>> From: Ramakrishna Saripalli <[email protected]>
>>
>> Certain AMD processors feature a new technology called Predictive Store
>> Forwarding (PSF).
>>
>> PSF is a micro-architectural optimization designed to improve the
>> performance of code execution by predicting dependencies between
>> loads and stores.
>>
>> Incorrect PSF predictions can occur due to two reasons.
>>
>> - It is possible that the load/store pair may have had dependency for
>> a while but the dependency has stopped because the address in the
>> load/store pair has changed.
>>
>> - Second source of incorrect PSF prediction can occur because of an alias
>> in the PSF predictor structure stored in the microarchitectural state.
>> PSF predictor tracks load/store pair based on portions of instruction
>> pointer. It is possible that a load/store pair which does have a
>> dependency may be aliased by another load/store pair which does not have
>> the same dependency. This can result in incorrect speculation.
>>
>> Software may be able to detect this aliasing and perform side-channel
>> attacks.
>
> So this is the new post spectre/meltdown/.../ world order.
>
> What would have been considered a potential speculative side channel bug
> two years ago is now sold a feature which is by default enabled.
>
> Just to be clear. From a security POV this is just yet another
> default enabled speculative vulnerability. The difference to the others
> is that this is communicated upfront and comes with a knob to turn it
> off right away.
>
> There is also interaction with SSB and the SSB mitigation which is
> described in the cover letter, but not in the changelog and is not
> detectable from user space.
>
> I know that you had it implemented that way in your first attempt, but I
> was busy with other things and missed the discussion which resulted in
> this being treated as a feature.
>
> TBH, I'm not really happy about this because that's inconsistent with
> how we treat the other speculation related issues and there is no way
> for user space to actually check this like the other one via /sys/....
This patchset has come about to try to give the upstream community an initial feeling for this feature
with very simple controls (on and off) to experiment with this feature.
>
>> +++ b/arch/x86/kernel/cpu/amd.c
>> @@ -1170,3 +1170,22 @@ void set_dr_addr_mask(unsigned long mask, int dr)
>> break;
>> }
>> }
>> +
>> +static int __init psf_cmdline(char *str)
>> +{
>> + if (!boot_cpu_has(X86_FEATURE_PSFD))
>> + return 0;
>> +
>> + if (!str)
>> + return -EINVAL;
>> +
>> + if (!strcmp(str, "off")) {
>> + set_cpu_cap(&boot_cpu_data, X86_FEATURE_MSR_SPEC_CTRL);
>
> What? Why is this setting this feature here and why is this not done in
> init_speculation_control() as for all the other speculation misfeatures?
First patchset indeed was treating PSF similar to other features but it was decided based
on reviews to trim it down and present a very simple set of controls.
>
>> + x86_spec_ctrl_base |= SPEC_CTRL_PSFD;
>
> What? See below.
>
>> + msr_set_bit(MSR_IA32_SPEC_CTRL, SPEC_CTRL_PSFD_SHIFT);
>> + }
>> +
>> + return 0;
>
> So any parameter is treated as valid here. That's interesting at best.
>
>> --- a/arch/x86/kernel/cpu/bugs.c
>> +++ b/arch/x86/kernel/cpu/bugs.c
>> @@ -78,6 +78,8 @@ EXPORT_SYMBOL_GPL(mds_idle_clear);
>>
>> void __init check_bugs(void)
>> {
>> + u64 tmp = 0;
>> +
>> identify_boot_cpu();
>>
>> /*
>> @@ -97,7 +99,9 @@ void __init check_bugs(void)
>> * init code as it is not enumerated and depends on the family.
>> */
>> if (boot_cpu_has(X86_FEATURE_MSR_SPEC_CTRL))
>> - rdmsrl(MSR_IA32_SPEC_CTRL, x86_spec_ctrl_base);
>> + rdmsrl(MSR_IA32_SPEC_CTRL, tmp);
>> +
>> + x86_spec_ctrl_base |= tmp;
>
> How is anyone supposed to understand that logic?
>
> Just because x86_spec_ctrl_base is a global variable does not justify
> this hackery at all. It's just a matter of time that someone reads this:
>
> u64 x86_spec_ctrl_base;
>
> void __init check_bugs(void)
> {
> u64 tmp = 0;
>
> ...
>
> if (boot_cpu_has(X86_FEATURE_MSR_SPEC_CTRL))
> rdmsrl(MSR_IA32_SPEC_CTRL, tmp);
>
> x86_spec_ctrl_base |= tmp;
>
> and figures that this is a pointless exercise and reverts that hunk.
>
> What's wrong with just treating this in the same way in which we treat
> all other speculative vulnerabilities and provide a consistent picture
> to the user?
>
> Something like the below. You get the idea.
I agree and the first patchset did indeed treat this vulnerability just
like others. It was converted to this patchset based on reviews from the upstream
community.
>
> Thanks,
>
> tglx
> ---
> --- a/arch/x86/kernel/cpu/bugs.c
> +++ b/arch/x86/kernel/cpu/bugs.c
> @@ -111,6 +111,7 @@ void __init check_bugs(void)
> mds_select_mitigation();
> taa_select_mitigation();
> srbds_select_mitigation();
> + psf_select_mitigation();
>
> /*
> * As MDS and TAA mitigations are inter-related, print MDS
> --- a/arch/x86/kernel/cpu/common.c
> +++ b/arch/x86/kernel/cpu/common.c
> @@ -891,6 +891,9 @@ static void init_speculation_control(str
> set_cpu_cap(c, X86_FEATURE_MSR_SPEC_CTRL);
> clear_cpu_cap(c, X86_FEATURE_VIRT_SSBD);
> }
> +
> + if (!boot_cpu_has(X86_FEATURE_PSFD))
> + set_cpu_cap(c, X86_FEATURE_MSR_SPEC_CTRL);
> }
>
> void get_cpu_cap(struct cpuinfo_x86 *c)
>
On Fri, May 07 2021 at 10:23, RK Saripalli wrote:
> On 5/7/2021 10:13 AM, Thomas Gleixner wrote:
>> Something like the below. You get the idea.
>
> I agree and the first patchset did indeed treat this vulnerability just
> like others. It was converted to this patchset based on reviews from the upstream
> community.
Yes, I saw that and said so.
But I fundamentaly disagree with that for the reasons I mentioned. Sorry
for not paying attention early on.
Thanks,
tglx
On 5/7/2021 10:13 AM, Thomas Gleixner wrote:
> On Wed, May 05 2021 at 14:09, Ramakrishna Saripalli wrote:
>> From: Ramakrishna Saripalli <[email protected]>
>>
>> Certain AMD processors feature a new technology called Predictive Store
>> Forwarding (PSF).
>>
>> PSF is a micro-architectural optimization designed to improve the
>> performance of code execution by predicting dependencies between
>> loads and stores.
>>
>> Incorrect PSF predictions can occur due to two reasons.
>>
>> - It is possible that the load/store pair may have had dependency for
>> a while but the dependency has stopped because the address in the
>> load/store pair has changed.
>>
>> - Second source of incorrect PSF prediction can occur because of an alias
>> in the PSF predictor structure stored in the microarchitectural state.
>> PSF predictor tracks load/store pair based on portions of instruction
>> pointer. It is possible that a load/store pair which does have a
>> dependency may be aliased by another load/store pair which does not have
>> the same dependency. This can result in incorrect speculation.
>>
>> Software may be able to detect this aliasing and perform side-channel
>> attacks.
>
> So this is the new post spectre/meltdown/.../ world order.
>
> What would have been considered a potential speculative side channel bug
> two years ago is now sold a feature which is by default enabled.
>
> Just to be clear. From a security POV this is just yet another
> default enabled speculative vulnerability. The difference to the others
> is that this is communicated upfront and comes with a knob to turn it
> off right away.
>
> There is also interaction with SSB and the SSB mitigation which is
> described in the cover letter, but not in the changelog and is not
> detectable from user space.
>
> I know that you had it implemented that way in your first attempt, but I
> was busy with other things and missed the discussion which resulted in
> this being treated as a feature.
>
> TBH, I'm not really happy about this because that's inconsistent with
> how we treat the other speculation related issues and there is no way
> for user space to actually check this like the other one via /sys/....
>
>> +++ b/arch/x86/kernel/cpu/amd.c
>> @@ -1170,3 +1170,22 @@ void set_dr_addr_mask(unsigned long mask, int dr)
>> break;
>> }
>> }
>> +
>> +static int __init psf_cmdline(char *str)
>> +{
>> + if (!boot_cpu_has(X86_FEATURE_PSFD))
>> + return 0;
>> +
>> + if (!str)
>> + return -EINVAL;
>> +
>> + if (!strcmp(str, "off")) {
>> + set_cpu_cap(&boot_cpu_data, X86_FEATURE_MSR_SPEC_CTRL);
>
> What? Why is this setting this feature here and why is this not done in
> init_speculation_control() as for all the other speculation misfeatures?
>
>> + x86_spec_ctrl_base |= SPEC_CTRL_PSFD;
>
> What? See below.
>
>> + msr_set_bit(MSR_IA32_SPEC_CTRL, SPEC_CTRL_PSFD_SHIFT);
>> + }
>> +
>> + return 0;
>
> So any parameter is treated as valid here. That's interesting at best.
>
>> --- a/arch/x86/kernel/cpu/bugs.c
>> +++ b/arch/x86/kernel/cpu/bugs.c
>> @@ -78,6 +78,8 @@ EXPORT_SYMBOL_GPL(mds_idle_clear);
>>
>> void __init check_bugs(void)
>> {
>> + u64 tmp = 0;
>> +
>> identify_boot_cpu();
>>
>> /*
>> @@ -97,7 +99,9 @@ void __init check_bugs(void)
>> * init code as it is not enumerated and depends on the family.
>> */
>> if (boot_cpu_has(X86_FEATURE_MSR_SPEC_CTRL))
>> - rdmsrl(MSR_IA32_SPEC_CTRL, x86_spec_ctrl_base);
>> + rdmsrl(MSR_IA32_SPEC_CTRL, tmp);
>> +
>> + x86_spec_ctrl_base |= tmp;
>
> How is anyone supposed to understand that logic?
>
> Just because x86_spec_ctrl_base is a global variable does not justify
> this hackery at all. It's just a matter of time that someone reads this:
>
> u64 x86_spec_ctrl_base;
>
> void __init check_bugs(void)
> {
> u64 tmp = 0;
>
> ...
>
> if (boot_cpu_has(X86_FEATURE_MSR_SPEC_CTRL))
> rdmsrl(MSR_IA32_SPEC_CTRL, tmp);
>
> x86_spec_ctrl_base |= tmp;
>
> and figures that this is a pointless exercise and reverts that hunk.
>
> What's wrong with just treating this in the same way in which we treat
> all other speculative vulnerabilities and provide a consistent picture
> to the user?
>
> Something like the below. You get the idea.
Thomas, thank you very much for the comments.
I provided the links to the original patches which treat PSF similar to other
speculative vulnerabilities.
Could you review them please?. The first patch is the cover letter.
https://lore.kernel.org/lkml/[email protected]/
https://lore.kernel.org/lkml/[email protected]/
https://lore.kernel.org/lkml/[email protected]/
https://lore.kernel.org/lkml/[email protected]/
https://lore.kernel.org/lkml/[email protected]/
https://lore.kernel.org/lkml/[email protected]/
Thanks,
RK
>
> Thanks,
>
> tglx
> ---
> --- a/arch/x86/kernel/cpu/bugs.c
> +++ b/arch/x86/kernel/cpu/bugs.c
> @@ -111,6 +111,7 @@ void __init check_bugs(void)
> mds_select_mitigation();
> taa_select_mitigation();
> srbds_select_mitigation();
> + psf_select_mitigation();
>
> /*
> * As MDS and TAA mitigations are inter-related, print MDS
> --- a/arch/x86/kernel/cpu/common.c
> +++ b/arch/x86/kernel/cpu/common.c
> @@ -891,6 +891,9 @@ static void init_speculation_control(str
> set_cpu_cap(c, X86_FEATURE_MSR_SPEC_CTRL);
> clear_cpu_cap(c, X86_FEATURE_VIRT_SSBD);
> }
> +
> + if (!boot_cpu_has(X86_FEATURE_PSFD))
> + set_cpu_cap(c, X86_FEATURE_MSR_SPEC_CTRL);
> }
>
> void get_cpu_cap(struct cpuinfo_x86 *c)
>
On Mon, May 10 2021 at 06:10, RK Saripalli wrote:
> On 5/7/2021 10:13 AM, Thomas Gleixner wrote:
>> What's wrong with just treating this in the same way in which we treat
>> all other speculative vulnerabilities and provide a consistent picture
>> to the user?
>>
>> Something like the below. You get the idea.
>
> Thomas, thank you very much for the comments.
>
> I provided the links to the original patches which treat PSF similar to other
> speculative vulnerabilities.
>
> Could you review them please?. The first patch is the cover letter.
>
> https://lore.kernel.org/lkml/[email protected]/
> https://lore.kernel.org/lkml/[email protected]/
> https://lore.kernel.org/lkml/[email protected]/
> https://lore.kernel.org/lkml/[email protected]/
> https://lore.kernel.org/lkml/[email protected]/
> https://lore.kernel.org/lkml/[email protected]/
They are going into the right direction, i.e. detection and reporting.
Vs. mitigation control the question is whether we need the full
machinery of prctl/seccomp and so forth especially under the aspect that
the SSBD mitigation already covers the PSF issue.
So for the start a simple on/off might be good enough.
Kees, any opinions?
Thanks,
tglx
On 5/10/2021 4:44 PM, Thomas Gleixner wrote:
> On Mon, May 10 2021 at 06:10, RK Saripalli wrote:
>> On 5/7/2021 10:13 AM, Thomas Gleixner wrote:
>>> What's wrong with just treating this in the same way in which we treat
>>> all other speculative vulnerabilities and provide a consistent picture
>>> to the user?
>>>
>>> Something like the below. You get the idea.
>>
>> Thomas, thank you very much for the comments.
>>
>> I provided the links to the original patches which treat PSF similar to other
>> speculative vulnerabilities.
>>
>> Could you review them please?. The first patch is the cover letter.
>>
>> https://lore.kernel.org/lkml/[email protected]/
>> https://lore.kernel.org/lkml/[email protected]/
>> https://lore.kernel.org/lkml/[email protected]/
>> https://lore.kernel.org/lkml/[email protected]/
>> https://lore.kernel.org/lkml/[email protected]/
>> https://lore.kernel.org/lkml/[email protected]/
>
> They are going into the right direction, i.e. detection and reporting.
>
> Vs. mitigation control the question is whether we need the full
> machinery of prctl/seccomp and so forth especially under the aspect that
> the SSBD mitigation already covers the PSF issue.
>
> So for the start a simple on/off might be good enough.
Thomas, I am fine with that. To a large extent, the new set of patches do that (on and off)
but they are not in the same files as other mitigations.
If I understand you correctly, you would prefer the on/off in bugs.c so that the changes
stay with other mitigation controls.
Thanks for reviewing and I will wait for feedback from Kees.
RK
>
> Kees, any opinions?
>
> Thanks,
>
> tglx
>
On Mon, May 10, 2021 at 11:44:03PM +0200, Thomas Gleixner wrote:
> On Mon, May 10 2021 at 06:10, RK Saripalli wrote:
> > On 5/7/2021 10:13 AM, Thomas Gleixner wrote:
> >> What's wrong with just treating this in the same way in which we treat
> >> all other speculative vulnerabilities and provide a consistent picture
> >> to the user?
> >>
> >> Something like the below. You get the idea.
> >
> > Thomas, thank you very much for the comments.
> >
> > I provided the links to the original patches which treat PSF similar to other
> > speculative vulnerabilities.
> >
> > Could you review them please?. The first patch is the cover letter.
> >
> > https://lore.kernel.org/lkml/[email protected]/
> > https://lore.kernel.org/lkml/[email protected]/
> > https://lore.kernel.org/lkml/[email protected]/
> > https://lore.kernel.org/lkml/[email protected]/
> > https://lore.kernel.org/lkml/[email protected]/
> > https://lore.kernel.org/lkml/[email protected]/
>
> They are going into the right direction, i.e. detection and reporting.
>
> Vs. mitigation control the question is whether we need the full
> machinery of prctl/seccomp and so forth especially under the aspect that
> the SSBD mitigation already covers the PSF issue.
>
> So for the start a simple on/off might be good enough.
>
> Kees, any opinions?
I agree: if PSF is a subset of SSBD, there's no need for the additional
machinery.
On a related topic, what happened to Andi's patch to switch the seccomp
defaults? I can't find it now...
--
Kees Cook
On Mon, May 10 2021 at 15:09, Kees Cook wrote:
> On Mon, May 10, 2021 at 11:44:03PM +0200, Thomas Gleixner wrote:
>> Kees, any opinions?
>
> I agree: if PSF is a subset of SSBD, there's no need for the additional
> machinery.
>
> On a related topic, what happened to Andi's patch to switch the seccomp
> defaults? I can't find it now...
You mean this one:
https://lore.kernel.org/r/[email protected]
If so, then it has lacks a follow up.
Thanks,
tglx
On Tue, May 11, 2021 at 12:15:32AM +0200, Thomas Gleixner wrote:
> On Mon, May 10 2021 at 15:09, Kees Cook wrote:
> > On Mon, May 10, 2021 at 11:44:03PM +0200, Thomas Gleixner wrote:
> >> Kees, any opinions?
> >
> > I agree: if PSF is a subset of SSBD, there's no need for the additional
> > machinery.
> >
> > On a related topic, what happened to Andi's patch to switch the seccomp
> > defaults? I can't find it now...
>
> You mean this one:
>
> https://lore.kernel.org/r/[email protected]
>
> If so, then it has lacks a follow up.
I swear there was a follow-up to this. I will try to find it again.
--
Kees Cook
On Tue, May 11, 2021 at 12:15:32AM +0200, Thomas Gleixner wrote:
> On Mon, May 10 2021 at 15:09, Kees Cook wrote:
> > On Mon, May 10, 2021 at 11:44:03PM +0200, Thomas Gleixner wrote:
> >> Kees, any opinions?
> >
> > I agree: if PSF is a subset of SSBD, there's no need for the additional
> > machinery.
> >
> > On a related topic, what happened to Andi's patch to switch the seccomp
> > defaults? I can't find it now...
>
> You mean this one:
>
> https://lore.kernel.org/r/[email protected]
>
> If so, then it has lacks a follow up.
Ah-ha, found it. I misremembered the author. :)
https://lore.kernel.org/lkml/[email protected]/
Specifically these two patches:
https://lore.kernel.org/lkml/[email protected]/
https://lore.kernel.org/lkml/[email protected]/
And, Thomas, while I have your attention, I'd really like this to go in
for -rc2, if you can snag it:
https://lore.kernel.org/lkml/[email protected]/
:)
Thanks!
--
Kees Cook