From: Michael Ellerman <mpe@ellerman.id.au> Date: 2018-03-27 12:02:10
This commit adds security feature flags to reflect the settings we
receive from firmware regarding Spectre/Meltdown mitigations.
The feature names reflect the names we are given by firmware on bare
metal machines. See the hostboot source for details.
Arguably these could be firmware features, but that then requires them
to be read early in boot so they're available prior to asm feature
patching, but we don't actually want to use them for patching. We may
also want to dynamically update them in future, which would be
incompatible with the way firmware features work (at the moment at
least). So for now just make them separate flags.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/include/asm/security_features.h | 65 ++++++++++++++++++++++++++++
arch/powerpc/kernel/Makefile | 2 +-
arch/powerpc/kernel/security.c | 15 +++++++
3 files changed, 81 insertions(+), 1 deletion(-)
create mode 100644 arch/powerpc/include/asm/security_features.h
create mode 100644 arch/powerpc/kernel/security.c
v2: Rebased on top of LPM changes.
@@ -0,0 +1,65 @@+/* SPDX-License-Identifier: GPL-2.0+ */+/*+*Securityrelatedfeaturebitdefinitions.+*+*Copyright2018,MichaelEllerman,IBMCorporation.+*/++#ifndef _ASM_POWERPC_SECURITY_FEATURES_H+#define _ASM_POWERPC_SECURITY_FEATURES_H+++externunsignedlongpowerpc_security_features;++staticinlinevoidsecurity_ftr_set(unsignedlongfeature)+{+powerpc_security_features|=feature;+}++staticinlinevoidsecurity_ftr_clear(unsignedlongfeature)+{+powerpc_security_features&=~feature;+}++staticinlineboolsecurity_ftr_enabled(unsignedlongfeature)+{+return!!(powerpc_security_features&feature);+}+++// Features indicating support for Spectre/Meltdown mitigations++// The L1-D cache can be flushed with ori r30,r30,0+#define SEC_FTR_L1D_FLUSH_ORI30 0x0000000000000001ull++// The L1-D cache can be flushed with mtspr 882,r0 (aka SPRN_TRIG2)+#define SEC_FTR_L1D_FLUSH_TRIG2 0x0000000000000002ull++// ori r31,r31,0 acts as a speculation barrier+#define SEC_FTR_SPEC_BAR_ORI31 0x0000000000000004ull++// Speculation past bctr is disabled+#define SEC_FTR_BCCTRL_SERIALISED 0x0000000000000008ull++// Entries in L1-D are private to a SMT thread+#define SEC_FTR_L1D_THREAD_PRIV 0x0000000000000010ull++// Indirect branch prediction cache disabled+#define SEC_FTR_COUNT_CACHE_DISABLED 0x0000000000000020ull+++// Features indicating need for Spectre/Meltdown mitigations++// The L1-D cache should be flushed on MSR[HV] 1->0 transition (hypervisor to guest)+#define SEC_FTR_L1D_FLUSH_HV 0x0000000000000040ull++// The L1-D cache should be flushed on MSR[PR] 0->1 transition (kernel to userspace)+#define SEC_FTR_L1D_FLUSH_PR 0x0000000000000080ull++// A speculation barrier should be used for bounds checks (Spectre variant 1)+#define SEC_FTR_BNDS_CHK_SPEC_BAR 0x0000000000000100ull++// Firmware configuration indicates user favours security over performance+#define SEC_FTR_FAVOUR_SECURITY 0x0000000000000200ull++#endif /* _ASM_POWERPC_SECURITY_FEATURES_H */
@@ -0,0 +1,15 @@+// SPDX-License-Identifier: GPL-2.0++//+// Security related flags and so on.+//+// Copyright 2018, Michael Ellerman, IBM Corporation.++#include<linux/kernel.h>+#include<asm/security_features.h>+++unsignedlongpowerpc_security_features__read_mostly=\+SEC_FTR_L1D_FLUSH_HV|\+SEC_FTR_L1D_FLUSH_PR|\+SEC_FTR_BNDS_CHK_SPEC_BAR|\+SEC_FTR_FAVOUR_SECURITY;
From: Michael Ellerman <mpe@ellerman.id.au> Date: 2018-03-27 12:02:11
Add some additional values which have been defined for the
H_GET_CPU_CHARACTERISTICS hypercall.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/include/asm/hvcall.h | 3 +++
1 file changed, 3 insertions(+)
@@ -337,6 +337,9 @@#define H_CPU_CHAR_L1D_FLUSH_ORI30 (1ull << 61) // IBM bit 2#define H_CPU_CHAR_L1D_FLUSH_TRIG2 (1ull << 60) // IBM bit 3#define H_CPU_CHAR_L1D_THREAD_PRIV (1ull << 59) // IBM bit 4+#define H_CPU_CHAR_BRANCH_HINTS_HONORED (1ull << 58) // IBM bit 5+#define H_CPU_CHAR_THREAD_RECONFIG_CTRL (1ull << 57) // IBM bit 6+#define H_CPU_CHAR_COUNT_CACHE_DISABLED (1ull << 56) // IBM bit 7#define H_CPU_BEHAV_FAVOUR_SECURITY (1ull << 63) // IBM bit 0#define H_CPU_BEHAV_L1D_FLUSH_PR (1ull << 62) // IBM bit 1
From: Michael Ellerman <mpe@ellerman.id.au> Date: 2018-03-27 12:02:13
Now that we have feature flags for security related things, set or
clear them based on what we receive from the hypercall.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/platforms/pseries/setup.c | 43 ++++++++++++++++++++++++++++++++++
1 file changed, 43 insertions(+)
From: Michael Ellerman <mpe@ellerman.id.au> Date: 2018-03-27 12:02:15
Now that we have feature flags for security related things, set or
clear them based on what we see in the device tree provided by
firmware.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/platforms/powernv/setup.c | 56 ++++++++++++++++++++++++++++++++++
1 file changed, 56 insertions(+)
From: Michael Ellerman <mpe@ellerman.id.au> Date: 2018-03-27 12:02:15
This landed in setup_64.c for no good reason other than we had nowhere
else to put it. Now that we have a security-related file, that is a
better place for it so move it.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/kernel/security.c | 11 +++++++++++
arch/powerpc/kernel/setup_64.c | 8 --------
2 files changed, 11 insertions(+), 8 deletions(-)
@@ -5,6 +5,8 @@// Copyright 2018, Michael Ellerman, IBM Corporation.#include<linux/kernel.h>+#include<linux/device.h>+#include<asm/security_features.h>
From: Michael Ellerman <mpe@ellerman.id.au> Date: 2018-03-27 12:02:16
Now that we have the security feature flags we can make the
information displayed in the "meltdown" file more informative.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/include/asm/security_features.h | 1 +
arch/powerpc/kernel/security.c | 30 ++++++++++++++++++++++++++--
2 files changed, 29 insertions(+), 2 deletions(-)
From: Michael Ellerman <mpe@ellerman.id.au> Date: 2018-03-27 12:02:17
Now that we have the security flags we can significantly simplify the
code in pnv_setup_rfi_flush(), because we can use the flags instead of
checking device tree properties and because the security flags have
pessimistic defaults.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/platforms/powernv/setup.c | 41 +++++++++-------------------------
1 file changed, 10 insertions(+), 31 deletions(-)
@@ -99,11 +99,10 @@ static void pnv_setup_rfi_flush(void){structdevice_node*np,*fw_features;enuml1d_flush_typetype;-intenable;+boolenable;/* Default to fallback in case fw-features are not available */type=L1D_FLUSH_FALLBACK;-enable=1;np=of_find_node_by_name(NULL,"ibm,opal");fw_features=of_get_child_by_name(np,"fw-features");
@@ -111,40 +110,20 @@ static void pnv_setup_rfi_flush(void)if(fw_features){init_fw_feat_flags(fw_features);+of_node_put(fw_features);-np=of_get_child_by_name(fw_features,"inst-l1d-flush-trig2");-if(np&&of_property_read_bool(np,"enabled"))+if(security_ftr_enabled(SEC_FTR_L1D_FLUSH_TRIG2))type=L1D_FLUSH_MTTRIG;-of_node_put(np);--np=of_get_child_by_name(fw_features,"inst-l1d-flush-ori30,30,0");-if(np&&of_property_read_bool(np,"enabled"))+if(security_ftr_enabled(SEC_FTR_L1D_FLUSH_ORI30))type=L1D_FLUSH_ORI;--of_node_put(np);--/* Enable unless firmware says NOT to */-enable=2;-np=of_get_child_by_name(fw_features,"needs-l1d-flush-msr-hv-1-to-0");-if(np&&of_property_read_bool(np,"disabled"))-enable--;--of_node_put(np);--np=of_get_child_by_name(fw_features,"needs-l1d-flush-msr-pr-0-to-1");-if(np&&of_property_read_bool(np,"disabled"))-enable--;--np=of_get_child_by_name(fw_features,"speculation-policy-favor-security");-if(np&&of_property_read_bool(np,"disabled"))-enable=0;--of_node_put(np);-of_node_put(fw_features);}-setup_rfi_flush(type,enable>0);+enable=security_ftr_enabled(SEC_FTR_FAVOUR_SECURITY)&&\+(security_ftr_enabled(SEC_FTR_L1D_FLUSH_PR)||\+security_ftr_enabled(SEC_FTR_L1D_FLUSH_HV));++setup_rfi_flush(type,enable);}staticvoid__initpnv_setup_arch(void)
From: Michael Ellerman <mpe@ellerman.id.au> Date: 2018-03-27 12:02:18
Now that we have the security flags we can simplify the code in
pseries_setup_rfi_flush() because the security flags have pessimistic
defaults.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/platforms/pseries/setup.c | 27 ++++++++++++---------------
1 file changed, 12 insertions(+), 15 deletions(-)
From: Michael Ellerman <mpe@ellerman.id.au> Date: 2018-03-27 12:02:20
Add a definition for cpu_show_spectre_v1() to override the generic
version. Currently this just prints "Not affected" or "Vulnerable"
based on the firmware flag.
Although the kernel does have array_index_nospec() in a few places, we
haven't yet audited all the powerpc code to see where it's necessary,
so for now we don't list that as a mitigation.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/kernel/security.c | 8 ++++++++
1 file changed, 8 insertions(+)
From: Michael Ellerman <mpe@ellerman.id.au> Date: 2018-03-27 12:02:21
Add a definition for cpu_show_spectre_v2() to override the generic
version. This has several permuations, though in practice some may not
occur we cater for any combination.
The most verbose is:
Mitigation: Indirect branch serialisation (kernel only), Indirect
branch cache disabled, ori31 speculation barrier enabled
We don't treat the ori31 speculation barrier as a mitigation on its
own, because it has to be *used* by code in order to be a mitigation
and we don't know if userspace is doing that. So if that's all we see
we say:
Vulnerable, ori31 speculation barrier enabled
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/kernel/security.c | 33 +++++++++++++++++++++++++++++++++
1 file changed, 33 insertions(+)
unscribed me
On Tuesday, March 27, 2018 05:31:31 AM PDT, Michael Ellerman [off-list ref] wrote:
Add a definition for cpu_show_spectre_v2() to override the generic
version. This has several permuations, though in practice some may not
occur we cater for any combination.
The most verbose is:
Mitigation: Indirect branch serialisation (kernel only), Indirect
branch cache disabled, ori31 speculation barrier enabled
We don't treat the ori31 speculation barrier as a mitigation on its
own, because it has to be *used* by code in order to be a mitigation
and we don't know if userspace is doing that. So if that's all we see
we say:
Vulnerable, ori31 speculation barrier enabled
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/kernel/security.c | 33 +++++++++++++++++++++++++++++++++
1 file changed, 33 insertions(+)
From: Gabriel Paubert <hidden> Date: 2018-03-27 13:57:00
On Tue, Mar 27, 2018 at 11:01:44PM +1100, Michael Ellerman wrote:
quoted hunk
This commit adds security feature flags to reflect the settings we
receive from firmware regarding Spectre/Meltdown mitigations.
The feature names reflect the names we are given by firmware on bare
metal machines. See the hostboot source for details.
Arguably these could be firmware features, but that then requires them
to be read early in boot so they're available prior to asm feature
patching, but we don't actually want to use them for patching. We may
also want to dynamically update them in future, which would be
incompatible with the way firmware features work (at the moment at
least). So for now just make them separate flags.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/include/asm/security_features.h | 65 ++++++++++++++++++++++++++++
arch/powerpc/kernel/Makefile | 2 +-
arch/powerpc/kernel/security.c | 15 +++++++
3 files changed, 81 insertions(+), 1 deletion(-)
create mode 100644 arch/powerpc/include/asm/security_features.h
create mode 100644 arch/powerpc/kernel/security.c
v2: Rebased on top of LPM changes.
@@ -0,0 +1,65 @@+/* SPDX-License-Identifier: GPL-2.0+ */+/*+*Securityrelatedfeaturebitdefinitions.+*+*Copyright2018,MichaelEllerman,IBMCorporation.+*/++#ifndef _ASM_POWERPC_SECURITY_FEATURES_H+#define _ASM_POWERPC_SECURITY_FEATURES_H+++externunsignedlongpowerpc_security_features;++staticinlinevoidsecurity_ftr_set(unsignedlongfeature)+{+powerpc_security_features|=feature;+}++staticinlinevoidsecurity_ftr_clear(unsignedlongfeature)+{+powerpc_security_features&=~feature;+}++staticinlineboolsecurity_ftr_enabled(unsignedlongfeature)+{+return!!(powerpc_security_features&feature);+}+++// Features indicating support for Spectre/Meltdown mitigations++// The L1-D cache can be flushed with ori r30,r30,0+#define SEC_FTR_L1D_FLUSH_ORI30 0x0000000000000001ull++// The L1-D cache can be flushed with mtspr 882,r0 (aka SPRN_TRIG2)+#define SEC_FTR_L1D_FLUSH_TRIG2 0x0000000000000002ull++// ori r31,r31,0 acts as a speculation barrier+#define SEC_FTR_SPEC_BAR_ORI31 0x0000000000000004ull++// Speculation past bctr is disabled+#define SEC_FTR_BCCTRL_SERIALISED 0x0000000000000008ull
Nitpicks:
1) bcctr or bcctrL ?
2) seraliaZe seems to be more popular than serialiSe in the kernel
(1769 hits from "grep -ir serializ", 264 with the "s")
Still needs to grep for both in any case, bummer!
Gabriel
quoted hunk
+
+// Entries in L1-D are private to a SMT thread
+#define SEC_FTR_L1D_THREAD_PRIV 0x0000000000000010ull
+
+// Indirect branch prediction cache disabled
+#define SEC_FTR_COUNT_CACHE_DISABLED 0x0000000000000020ull
+
+
+// Features indicating need for Spectre/Meltdown mitigations
+
+// The L1-D cache should be flushed on MSR[HV] 1->0 transition (hypervisor to guest)
+#define SEC_FTR_L1D_FLUSH_HV 0x0000000000000040ull
+
+// The L1-D cache should be flushed on MSR[PR] 0->1 transition (kernel to userspace)
+#define SEC_FTR_L1D_FLUSH_PR 0x0000000000000080ull
+
+// A speculation barrier should be used for bounds checks (Spectre variant 1)
+#define SEC_FTR_BNDS_CHK_SPEC_BAR 0x0000000000000100ull
+
+// Firmware configuration indicates user favours security over performance
+#define SEC_FTR_FAVOUR_SECURITY 0x0000000000000200ull
+
+#endif /* _ASM_POWERPC_SECURITY_FEATURES_H */
@@ -0,0 +1,15 @@+// SPDX-License-Identifier: GPL-2.0++//+// Security related flags and so on.+//+// Copyright 2018, Michael Ellerman, IBM Corporation.++#include<linux/kernel.h>+#include<asm/security_features.h>+++unsignedlongpowerpc_security_features__read_mostly=\+SEC_FTR_L1D_FLUSH_HV|\+SEC_FTR_L1D_FLUSH_PR|\+SEC_FTR_BNDS_CHK_SPEC_BAR|\+SEC_FTR_FAVOUR_SECURITY;
Why is the speculation barrier specific to Spectre v2? Can't the barrier=0A=
be used as a mitigation for Spectre v1 as well?=0A=
=0A=
Regards,=0A=
Diana=0A=
=0A=
On 3/27/2018 3:32 PM, Michael Ellerman wrote:=0A=
quoted hunk
Add a definition for cpu_show_spectre_v2() to override the generic=0A=
version. This has several permuations, though in practice some may not=0A=
occur we cater for any combination.=0A=
=0A=
The most verbose is:=0A=
=0A=
Mitigation: Indirect branch serialisation (kernel only), Indirect=0A=
branch cache disabled, ori31 speculation barrier enabled=0A=
=0A=
We don't treat the ori31 speculation barrier as a mitigation on its=0A=
own, because it has to be *used* by code in order to be a mitigation=0A=
and we don't know if userspace is doing that. So if that's all we see=0A=
we say:=0A=
=0A=
Vulnerable, ori31 speculation barrier enabled=0A=
=0A=
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>=0A=
---=0A=
arch/powerpc/kernel/security.c | 33 +++++++++++++++++++++++++++++++++=0A=
1 file changed, 33 insertions(+)=0A=
=0A=
From: Michael Ellerman <hidden> Date: 2018-03-28 14:13:32
On Tue, 2018-03-27 at 12:01:44 UTC, Michael Ellerman wrote:
This commit adds security feature flags to reflect the settings we
receive from firmware regarding Spectre/Meltdown mitigations.
The feature names reflect the names we are given by firmware on bare
metal machines. See the hostboot source for details.
Arguably these could be firmware features, but that then requires them
to be read early in boot so they're available prior to asm feature
patching, but we don't actually want to use them for patching. We may
also want to dynamically update them in future, which would be
incompatible with the way firmware features work (at the moment at
least). So for now just make them separate flags.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
From: Mauricio Faria de Oliveira <hidden> Date: 2018-03-29 18:35:21
Hi Michael,
On 03/27/2018 09:01 AM, Michael Ellerman wrote:
+ if (!(result->character & H_CPU_BEHAV_FAVOUR_SECURITY))
+ security_ftr_clear(SEC_FTR_FAVOUR_SECURITY);
+
+ if (!(result->character & H_CPU_BEHAV_L1D_FLUSH_PR))
+ security_ftr_clear(SEC_FTR_L1D_FLUSH_PR);
+
+ if (!(result->character & H_CPU_BEHAV_BNDS_CHK_SPEC_BAR))
+ security_ftr_clear(SEC_FTR_BNDS_CHK_SPEC_BAR);
Oops, I missed this..
The H_CPU_BEHAV flags should be checked for in 'result->behaviour'.
Just sent '[PATCH] powerpc/pseries: Fix to clear security feature flags'
cheers,
Mauricio