| Message ID | 1515394416-166994-2-git-send-email-jnair@caviumnetworks.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Sun, Jan 07, 2018 at 10:53:36PM -0800, Jayachandran C wrote: > Use PSCI based mitigation for speculative execution attacks targeting > the branch predictor. The approach is similar to the one used for > Cortex-A CPUs, but in case of ThunderX2 we add another SMC call to > test if the firmware supports the capability. > > If the secure firmware has been updated with the mitigation code to > invalidate the branch target buffer, we use the PSCI version call to > invoke it. > > Signed-off-by: Jayachandran C <jnair@caviumnetworks.com> > --- > arch/arm64/kernel/cpu_errata.c | 38 ++++++++++++++++++++++++++++++++++++++ > 1 file changed, 38 insertions(+) > > diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c > index cb0fb37..abceb5d 100644 > --- a/arch/arm64/kernel/cpu_errata.c > +++ b/arch/arm64/kernel/cpu_errata.c > @@ -124,6 +124,7 @@ static void install_bp_hardening_cb(const struct arm64_cpu_capabilities *entry, > __install_bp_hardening_cb(fn, hyp_vecs_start, hyp_vecs_end); > } > > +#include <linux/arm-smccc.h> > #include <linux/psci.h> > > static int enable_psci_bp_hardening(void *data) > @@ -138,6 +139,33 @@ static int enable_psci_bp_hardening(void *data) > > return 0; > } > + > +#define CAVIUM_TX2_SIP_SMC_CALL 0xC200FF00 > +#define CAVIUM_TX2_BTB_HARDEN_CAP 0xB0A0 > + > +static int enable_tx2_psci_bp_hardening(void *data) > +{ > + const struct arm64_cpu_capabilities *entry = data; > + struct arm_smccc_res res; > + > + if (!entry->matches(entry, SCOPE_LOCAL_CPU)) > + return; > + > + arm_smccc_smc(CAVIUM_TX2_SIP_SMC_CALL, CAVIUM_TX2_BTB_HARDEN_CAP, 0, 0, 0, 0, 0, 0, &res); One thing to be aware of here is that if somebody configures qemu to emulate a TX2, this may actually disappear into EL3 and not return. You're better off sticking with PSCI GET_VERSION in terms of portability, but it's your call -- I'd expect you to deal with any breakage reports on the list due to the SMC above. Fair? > + if (res.a0 != 0) { > + pr_warn("Error: CONFIG_HARDEN_BRANCH_PREDICTOR enabled, but firmware does not support it\n"); > + return 0; > + } Please don't print this here; see below. > + if (res.a1 == 1 && psci_ops.get_version) { > + pr_info("CPU%d: Branch predictor hardening enabled\n", smp_processor_id()); If you want to print a message, please put it in the capability structure .desc field. Will
On Mon, Jan 08, 2018 at 04:46:52PM +0000, Will Deacon wrote: > On Sun, Jan 07, 2018 at 10:53:36PM -0800, Jayachandran C wrote: > > Use PSCI based mitigation for speculative execution attacks targeting > > the branch predictor. The approach is similar to the one used for > > Cortex-A CPUs, but in case of ThunderX2 we add another SMC call to > > test if the firmware supports the capability. > > > > If the secure firmware has been updated with the mitigation code to > > invalidate the branch target buffer, we use the PSCI version call to > > invoke it. > > > > Signed-off-by: Jayachandran C <jnair@caviumnetworks.com> > > --- > > arch/arm64/kernel/cpu_errata.c | 38 ++++++++++++++++++++++++++++++++++++++ > > 1 file changed, 38 insertions(+) > > > > diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c > > index cb0fb37..abceb5d 100644 > > --- a/arch/arm64/kernel/cpu_errata.c > > +++ b/arch/arm64/kernel/cpu_errata.c > > @@ -124,6 +124,7 @@ static void install_bp_hardening_cb(const struct arm64_cpu_capabilities *entry, > > __install_bp_hardening_cb(fn, hyp_vecs_start, hyp_vecs_end); > > } > > > > +#include <linux/arm-smccc.h> > > #include <linux/psci.h> > > > > static int enable_psci_bp_hardening(void *data) > > @@ -138,6 +139,33 @@ static int enable_psci_bp_hardening(void *data) > > > > return 0; > > } > > + > > +#define CAVIUM_TX2_SIP_SMC_CALL 0xC200FF00 > > +#define CAVIUM_TX2_BTB_HARDEN_CAP 0xB0A0 > > + > > +static int enable_tx2_psci_bp_hardening(void *data) > > +{ > > + const struct arm64_cpu_capabilities *entry = data; > > + struct arm_smccc_res res; > > + > > + if (!entry->matches(entry, SCOPE_LOCAL_CPU)) > > + return; > > + > > + arm_smccc_smc(CAVIUM_TX2_SIP_SMC_CALL, CAVIUM_TX2_BTB_HARDEN_CAP, 0, 0, 0, 0, 0, 0, &res); > > One thing to be aware of here is that if somebody configures qemu to emulate > a TX2, this may actually disappear into EL3 and not return. You're better > off sticking with PSCI GET_VERSION in terms of portability, but it's your > call -- I'd expect you to deal with any breakage reports on the list due > to the SMC above. Fair? I don't like having a custom SMC here either. But Overloading PSCI get version is the problem as I wrote earlier - there is no way to check if the firmware implements BTB hardening with overloading. There is a good chance that users with old firmware will just fail without any warning. Is there a reason for overloading PSCI get version? Allocating a new standard SMC number would make checking for existance and usage much simpler. I did not quite understand the possible issue in qemu, unimplemented SMC calls are expected to return an error code. What am I missing here? > > > + if (res.a0 != 0) { > > + pr_warn("Error: CONFIG_HARDEN_BRANCH_PREDICTOR enabled, but firmware does not support it\n"); > > + return 0; > > + } > > Please don't print this here; see below. > > > + if (res.a1 == 1 && psci_ops.get_version) { > > + pr_info("CPU%d: Branch predictor hardening enabled\n", smp_processor_id()); > > If you want to print a message, please put it in the capability structure > .desc field. Thanks, will fix this in the next rev. JC.
On Mon, Jan 08, 2018 at 09:19:43AM -0800, Jayachandran C wrote: > On Mon, Jan 08, 2018 at 04:46:52PM +0000, Will Deacon wrote: > > On Sun, Jan 07, 2018 at 10:53:36PM -0800, Jayachandran C wrote: > > > Use PSCI based mitigation for speculative execution attacks targeting > > > the branch predictor. The approach is similar to the one used for > > > Cortex-A CPUs, but in case of ThunderX2 we add another SMC call to > > > test if the firmware supports the capability. > > > > > > If the secure firmware has been updated with the mitigation code to > > > invalidate the branch target buffer, we use the PSCI version call to > > > invoke it. > > > > > > Signed-off-by: Jayachandran C <jnair@caviumnetworks.com> > > > --- > > > arch/arm64/kernel/cpu_errata.c | 38 ++++++++++++++++++++++++++++++++++++++ > > > 1 file changed, 38 insertions(+) > > > > > > diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c > > > index cb0fb37..abceb5d 100644 > > > --- a/arch/arm64/kernel/cpu_errata.c > > > +++ b/arch/arm64/kernel/cpu_errata.c > > > @@ -124,6 +124,7 @@ static void install_bp_hardening_cb(const struct arm64_cpu_capabilities *entry, > > > __install_bp_hardening_cb(fn, hyp_vecs_start, hyp_vecs_end); > > > } > > > > > > +#include <linux/arm-smccc.h> > > > #include <linux/psci.h> > > > > > > static int enable_psci_bp_hardening(void *data) > > > @@ -138,6 +139,33 @@ static int enable_psci_bp_hardening(void *data) > > > > > > return 0; > > > } > > > + > > > +#define CAVIUM_TX2_SIP_SMC_CALL 0xC200FF00 > > > +#define CAVIUM_TX2_BTB_HARDEN_CAP 0xB0A0 > > > + > > > +static int enable_tx2_psci_bp_hardening(void *data) > > > +{ > > > + const struct arm64_cpu_capabilities *entry = data; > > > + struct arm_smccc_res res; > > > + > > > + if (!entry->matches(entry, SCOPE_LOCAL_CPU)) > > > + return; > > > + > > > + arm_smccc_smc(CAVIUM_TX2_SIP_SMC_CALL, CAVIUM_TX2_BTB_HARDEN_CAP, 0, 0, 0, 0, 0, 0, &res); > > > > One thing to be aware of here is that if somebody configures qemu to emulate > > a TX2, this may actually disappear into EL3 and not return. You're better > > off sticking with PSCI GET_VERSION in terms of portability, but it's your > > call -- I'd expect you to deal with any breakage reports on the list due > > to the SMC above. Fair? > > I don't like having a custom SMC here either. But Overloading PSCI get version > is the problem as I wrote earlier - there is no way to check if the firmware > implements BTB hardening with overloading. There is a good chance that users > with old firmware will just fail without any warning. That's true, but there is precedent for this elsewhere. For example, CPU errata that require a firmware change are often not probable. Also, your SMC call won't always work (see the qemu comment below). Note that I'm not saying I won't take this code, just that you need to be aware of what you're doing. > Is there a reason for overloading PSCI get version? Allocating a new standard > SMC number would make checking for existance and usage much simpler. PSCI get version is what we have today. We're working on extending PSCI to allocate a new standard SMC number, but we need something that can be used with existing firmware too and standardisation doesn't happen overnight. > I did not quite understand the possible issue in qemu, unimplemented SMC calls > are expected to return an error code. What am I missing here? Qemu will inject them into EL3, and there might not be anything there. Will
On Mon, Jan 08, 2018 at 05:23:41PM +0000, Will Deacon wrote: > On Mon, Jan 08, 2018 at 09:19:43AM -0800, Jayachandran C wrote: > > On Mon, Jan 08, 2018 at 04:46:52PM +0000, Will Deacon wrote: > > > On Sun, Jan 07, 2018 at 10:53:36PM -0800, Jayachandran C wrote: > > > > Use PSCI based mitigation for speculative execution attacks targeting > > > > the branch predictor. The approach is similar to the one used for > > > > Cortex-A CPUs, but in case of ThunderX2 we add another SMC call to > > > > test if the firmware supports the capability. > > > > > > > > If the secure firmware has been updated with the mitigation code to > > > > invalidate the branch target buffer, we use the PSCI version call to > > > > invoke it. > > > > > > > > Signed-off-by: Jayachandran C <jnair@caviumnetworks.com> > > > > --- > > > > arch/arm64/kernel/cpu_errata.c | 38 ++++++++++++++++++++++++++++++++++++++ > > > > 1 file changed, 38 insertions(+) > > > > > > > > diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c > > > > index cb0fb37..abceb5d 100644 > > > > --- a/arch/arm64/kernel/cpu_errata.c > > > > +++ b/arch/arm64/kernel/cpu_errata.c > > > > @@ -124,6 +124,7 @@ static void install_bp_hardening_cb(const struct arm64_cpu_capabilities *entry, > > > > __install_bp_hardening_cb(fn, hyp_vecs_start, hyp_vecs_end); > > > > } > > > > > > > > +#include <linux/arm-smccc.h> > > > > #include <linux/psci.h> > > > > > > > > static int enable_psci_bp_hardening(void *data) > > > > @@ -138,6 +139,33 @@ static int enable_psci_bp_hardening(void *data) > > > > > > > > return 0; > > > > } > > > > + > > > > +#define CAVIUM_TX2_SIP_SMC_CALL 0xC200FF00 > > > > +#define CAVIUM_TX2_BTB_HARDEN_CAP 0xB0A0 > > > > + > > > > +static int enable_tx2_psci_bp_hardening(void *data) > > > > +{ > > > > + const struct arm64_cpu_capabilities *entry = data; > > > > + struct arm_smccc_res res; > > > > + > > > > + if (!entry->matches(entry, SCOPE_LOCAL_CPU)) > > > > + return; > > > > + > > > > + arm_smccc_smc(CAVIUM_TX2_SIP_SMC_CALL, CAVIUM_TX2_BTB_HARDEN_CAP, 0, 0, 0, 0, 0, 0, &res); > > > > > > One thing to be aware of here is that if somebody configures qemu to emulate > > > a TX2, this may actually disappear into EL3 and not return. You're better > > > off sticking with PSCI GET_VERSION in terms of portability, but it's your > > > call -- I'd expect you to deal with any breakage reports on the list due > > > to the SMC above. Fair? > > > > I don't like having a custom SMC here either. But Overloading PSCI get version > > is the problem as I wrote earlier - there is no way to check if the firmware > > implements BTB hardening with overloading. There is a good chance that users > > with old firmware will just fail without any warning. > > That's true, but there is precedent for this elsewhere. For example, CPU > errata that require a firmware change are often not probable. Also, your SMC > call won't always work (see the qemu comment below). Note that I'm not > saying I won't take this code, just that you need to be aware of what > you're doing. > > > Is there a reason for overloading PSCI get version? Allocating a new standard > > SMC number would make checking for existance and usage much simpler. > > PSCI get version is what we have today. We're working on extending PSCI to > allocate a new standard SMC number, but we need something that can be used > with existing firmware too and standardisation doesn't happen overnight. Can you hold this patchset until the SMC number is published? Otherwise we will end up with two incompatible interfaces, and the mess of supporting both. Or if there is a plan standardize this later, I can pickup a vendor specific SMC for now, and switch over to the standard one later. Any suggestions here? JC.
On Mon, Jan 08, 2018 at 06:26:20PM -0800, Jayachandran C wrote: > On Mon, Jan 08, 2018 at 05:23:41PM +0000, Will Deacon wrote: > > On Mon, Jan 08, 2018 at 09:19:43AM -0800, Jayachandran C wrote: > > > On Mon, Jan 08, 2018 at 04:46:52PM +0000, Will Deacon wrote: > > > > On Sun, Jan 07, 2018 at 10:53:36PM -0800, Jayachandran C wrote: > > > > > + arm_smccc_smc(CAVIUM_TX2_SIP_SMC_CALL, CAVIUM_TX2_BTB_HARDEN_CAP, 0, 0, 0, 0, 0, 0, &res); > > > > > > > > One thing to be aware of here is that if somebody configures qemu to emulate > > > > a TX2, this may actually disappear into EL3 and not return. You're better > > > > off sticking with PSCI GET_VERSION in terms of portability, but it's your > > > > call -- I'd expect you to deal with any breakage reports on the list due > > > > to the SMC above. Fair? > > > > > > I don't like having a custom SMC here either. But Overloading PSCI get version > > > is the problem as I wrote earlier - there is no way to check if the firmware > > > implements BTB hardening with overloading. There is a good chance that users > > > with old firmware will just fail without any warning. > > > > That's true, but there is precedent for this elsewhere. For example, CPU > > errata that require a firmware change are often not probable. Also, your SMC > > call won't always work (see the qemu comment below). Note that I'm not > > saying I won't take this code, just that you need to be aware of what > > you're doing. > > > > > Is there a reason for overloading PSCI get version? Allocating a new standard > > > SMC number would make checking for existance and usage much simpler. > > > > PSCI get version is what we have today. We're working on extending PSCI to > > allocate a new standard SMC number, but we need something that can be used > > with existing firmware too and standardisation doesn't happen overnight. > > Can you hold this patchset until the SMC number is published? Otherwise we > will end up with two incompatible interfaces, and the mess of supporting > both. This has already been queued, and will be necessary for older PSCI versions that can be extended to perform the BP invalidation in get version, but which cannot be upgraded to a newer version of the spec. But that's fine; we can support both interfaces because the new one will need to be discoverable anyway. > Or if there is a plan standardize this later, I can pickup a vendor specific > SMC for now, and switch over to the standard one later. Any suggestions here? I would suggest using GET VERSION for now and switching later, but it's entirely up to you. Wil
diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c index cb0fb37..abceb5d 100644 --- a/arch/arm64/kernel/cpu_errata.c +++ b/arch/arm64/kernel/cpu_errata.c @@ -124,6 +124,7 @@ static void install_bp_hardening_cb(const struct arm64_cpu_capabilities *entry, __install_bp_hardening_cb(fn, hyp_vecs_start, hyp_vecs_end); } +#include <linux/arm-smccc.h> #include <linux/psci.h> static int enable_psci_bp_hardening(void *data) @@ -138,6 +139,33 @@ static int enable_psci_bp_hardening(void *data) return 0; } + +#define CAVIUM_TX2_SIP_SMC_CALL 0xC200FF00 +#define CAVIUM_TX2_BTB_HARDEN_CAP 0xB0A0 + +static int enable_tx2_psci_bp_hardening(void *data) +{ + const struct arm64_cpu_capabilities *entry = data; + struct arm_smccc_res res; + + if (!entry->matches(entry, SCOPE_LOCAL_CPU)) + return; + + arm_smccc_smc(CAVIUM_TX2_SIP_SMC_CALL, CAVIUM_TX2_BTB_HARDEN_CAP, 0, 0, 0, 0, 0, 0, &res); + if (res.a0 != 0) { + pr_warn("Error: CONFIG_HARDEN_BRANCH_PREDICTOR enabled, but firmware does not support it\n"); + return 0; + } + if (res.a1 == 1 && psci_ops.get_version) { + pr_info("CPU%d: Branch predictor hardening enabled\n", smp_processor_id()); + install_bp_hardening_cb(entry, + (bp_hardening_cb_t)psci_ops.get_version, + __psci_hyp_bp_inval_start, + __psci_hyp_bp_inval_end); + } + + return 0; +} #endif /* CONFIG_HARDEN_BRANCH_PREDICTOR */ #define MIDR_RANGE(model, min, max) \ @@ -302,6 +330,16 @@ const struct arm64_cpu_capabilities arm64_errata[] = { MIDR_ALL_VERSIONS(MIDR_CORTEX_A75), .enable = enable_psci_bp_hardening, }, + { + .capability = ARM64_HARDEN_BRANCH_PREDICTOR, + MIDR_ALL_VERSIONS(MIDR_BRCM_VULCAN), + .enable = enable_tx2_psci_bp_hardening, + }, + { + .capability = ARM64_HARDEN_BRANCH_PREDICTOR, + MIDR_ALL_VERSIONS(MIDR_CAVIUM_THUNDERX2), + .enable = enable_tx2_psci_bp_hardening, + }, #endif { }
Use PSCI based mitigation for speculative execution attacks targeting the branch predictor. The approach is similar to the one used for Cortex-A CPUs, but in case of ThunderX2 we add another SMC call to test if the firmware supports the capability. If the secure firmware has been updated with the mitigation code to invalidate the branch target buffer, we use the PSCI version call to invoke it. Signed-off-by: Jayachandran C <jnair@caviumnetworks.com> --- arch/arm64/kernel/cpu_errata.c | 38 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 38 insertions(+)