| Message ID | 1515157961-20963-12-git-send-email-will.deacon@arm.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi Marc, Will, (SOB-chain suggests a missing From: tag on this and patch 7) On 05/01/18 13:12, Will Deacon wrote: > Cortex-A57, A72, A73 and A75 are susceptible to branch predictor aliasing > and can theoretically be attacked by malicious code. > > This patch implements a PSCI-based mitigation for these CPUs when available. > The call into firmware will invalidate the branch predictor state, preventing > any malicious entries from affecting other victim contexts. > > Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> > Signed-off-by: Will Deacon <will.deacon@arm.com> > diff --git a/arch/arm64/kernel/bpi.S b/arch/arm64/kernel/bpi.S > index 06a931eb2673..2e9146534174 100644 > --- a/arch/arm64/kernel/bpi.S > +++ b/arch/arm64/kernel/bpi.S > @@ -53,3 +53,27 @@ ENTRY(__bp_harden_hyp_vecs_start) > vectors __kvm_hyp_vector > .endr > ENTRY(__bp_harden_hyp_vecs_end) > +ENTRY(__psci_hyp_bp_inval_start) > + sub sp, sp, #(8 * 18) Where does 18 come from? Isn't this storing 9 sets of 16 bytes? > + stp x16, x17, [sp, #(16 * 0)] > + stp x14, x15, [sp, #(16 * 1)] > + stp x12, x13, [sp, #(16 * 2)] > + stp x10, x11, [sp, #(16 * 3)] > + stp x8, x9, [sp, #(16 * 4)] > + stp x6, x7, [sp, #(16 * 5)] > + stp x4, x5, [sp, #(16 * 6)] > + stp x2, x3, [sp, #(16 * 7)] > + stp x0, x1, [sp, #(18 * 8)] 16->18 typo? > + mov x0, #0x84000000 > + smc #0 > + ldp x16, x17, [sp, #(16 * 0)] > + ldp x14, x15, [sp, #(16 * 1)] > + ldp x12, x13, [sp, #(16 * 2)] > + ldp x10, x11, [sp, #(16 * 3)] > + ldp x8, x9, [sp, #(16 * 4)] > + ldp x6, x7, [sp, #(16 * 5)] > + ldp x4, x5, [sp, #(16 * 6)] > + ldp x2, x3, [sp, #(16 * 7)] > + ldp x0, x1, [sp, #(18 * 8)] > + add sp, sp, #(8 * 18) (and here?) > +ENTRY(__psci_hyp_bp_inval_end) Thanks, James
On 05/01/18 14:46, James Morse wrote: > Hi Marc, Will, > > (SOB-chain suggests a missing From: tag on this and patch 7) > > On 05/01/18 13:12, Will Deacon wrote: >> Cortex-A57, A72, A73 and A75 are susceptible to branch predictor aliasing >> and can theoretically be attacked by malicious code. >> >> This patch implements a PSCI-based mitigation for these CPUs when available. >> The call into firmware will invalidate the branch predictor state, preventing >> any malicious entries from affecting other victim contexts. >> >> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> >> Signed-off-by: Will Deacon <will.deacon@arm.com> > >> diff --git a/arch/arm64/kernel/bpi.S b/arch/arm64/kernel/bpi.S >> index 06a931eb2673..2e9146534174 100644 >> --- a/arch/arm64/kernel/bpi.S >> +++ b/arch/arm64/kernel/bpi.S >> @@ -53,3 +53,27 @@ ENTRY(__bp_harden_hyp_vecs_start) >> vectors __kvm_hyp_vector >> .endr >> ENTRY(__bp_harden_hyp_vecs_end) >> +ENTRY(__psci_hyp_bp_inval_start) > >> + sub sp, sp, #(8 * 18) > > Where does 18 come from? Isn't this storing 9 sets of 16 bytes? Or 18 registers of 8 bytes each. > >> + stp x16, x17, [sp, #(16 * 0)] >> + stp x14, x15, [sp, #(16 * 1)] >> + stp x12, x13, [sp, #(16 * 2)] >> + stp x10, x11, [sp, #(16 * 3)] >> + stp x8, x9, [sp, #(16 * 4)] >> + stp x6, x7, [sp, #(16 * 5)] >> + stp x4, x5, [sp, #(16 * 6)] >> + stp x2, x3, [sp, #(16 * 7)] > >> + stp x0, x1, [sp, #(18 * 8)] > > 16->18 typo? /me bashes head against keyboard, as this is likely to generate less crap then me trying to write something half correct... The fun part is that the Seattle box I booted yesterday with that crap is still happily churning along. I guess I'm corrupting something that really doesn't matter... > > >> + mov x0, #0x84000000 >> + smc #0 >> + ldp x16, x17, [sp, #(16 * 0)] >> + ldp x14, x15, [sp, #(16 * 1)] >> + ldp x12, x13, [sp, #(16 * 2)] >> + ldp x10, x11, [sp, #(16 * 3)] >> + ldp x8, x9, [sp, #(16 * 4)] >> + ldp x6, x7, [sp, #(16 * 5)] >> + ldp x4, x5, [sp, #(16 * 6)] >> + ldp x2, x3, [sp, #(16 * 7)] > >> + ldp x0, x1, [sp, #(18 * 8)] >> + add sp, sp, #(8 * 18) > > (and here?) Yup. Thanks for pointing that out. I'll fetch a brown paper bag. M.
On Fri, Jan 05, 2018 at 01:12:41PM +0000, Will Deacon wrote: > Cortex-A57, A72, A73 and A75 are susceptible to branch predictor aliasing > and can theoretically be attacked by malicious code. > > This patch implements a PSCI-based mitigation for these CPUs when available. > The call into firmware will invalidate the branch predictor state, preventing > any malicious entries from affecting other victim contexts. > > Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> > Signed-off-by: Will Deacon <will.deacon@arm.com> > --- > arch/arm64/kernel/bpi.S | 24 ++++++++++++++++++++++++ > arch/arm64/kernel/cpu_errata.c | 42 ++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 66 insertions(+) > > diff --git a/arch/arm64/kernel/bpi.S b/arch/arm64/kernel/bpi.S > index 06a931eb2673..2e9146534174 100644 > --- a/arch/arm64/kernel/bpi.S > +++ b/arch/arm64/kernel/bpi.S > @@ -53,3 +53,27 @@ ENTRY(__bp_harden_hyp_vecs_start) > vectors __kvm_hyp_vector > .endr > ENTRY(__bp_harden_hyp_vecs_end) > +ENTRY(__psci_hyp_bp_inval_start) > + sub sp, sp, #(8 * 18) > + stp x16, x17, [sp, #(16 * 0)] > + stp x14, x15, [sp, #(16 * 1)] > + stp x12, x13, [sp, #(16 * 2)] > + stp x10, x11, [sp, #(16 * 3)] > + stp x8, x9, [sp, #(16 * 4)] > + stp x6, x7, [sp, #(16 * 5)] > + stp x4, x5, [sp, #(16 * 6)] > + stp x2, x3, [sp, #(16 * 7)] > + stp x0, x1, [sp, #(18 * 8)] > + mov x0, #0x84000000 > + smc #0 > + ldp x16, x17, [sp, #(16 * 0)] > + ldp x14, x15, [sp, #(16 * 1)] > + ldp x12, x13, [sp, #(16 * 2)] > + ldp x10, x11, [sp, #(16 * 3)] > + ldp x8, x9, [sp, #(16 * 4)] > + ldp x6, x7, [sp, #(16 * 5)] > + ldp x4, x5, [sp, #(16 * 6)] > + ldp x2, x3, [sp, #(16 * 7)] > + ldp x0, x1, [sp, #(18 * 8)] > + add sp, sp, #(8 * 18) > +ENTRY(__psci_hyp_bp_inval_end) > diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c > index 16ea5c6f314e..cb0fb3796bb8 100644 > --- a/arch/arm64/kernel/cpu_errata.c > +++ b/arch/arm64/kernel/cpu_errata.c > @@ -53,6 +53,8 @@ static int cpu_enable_trap_ctr_access(void *__unused) > DEFINE_PER_CPU_READ_MOSTLY(struct bp_hardening_data, bp_hardening_data); > > #ifdef CONFIG_KVM > +extern char __psci_hyp_bp_inval_start[], __psci_hyp_bp_inval_end[]; > + > static void __copy_hyp_vect_bpi(int slot, const char *hyp_vecs_start, > const char *hyp_vecs_end) > { > @@ -94,6 +96,9 @@ static void __install_bp_hardening_cb(bp_hardening_cb_t fn, > spin_unlock(&bp_lock); > } > #else > +#define __psci_hyp_bp_inval_start NULL > +#define __psci_hyp_bp_inval_end NULL > + > static void __install_bp_hardening_cb(bp_hardening_cb_t fn, > const char *hyp_vecs_start, > const char *hyp_vecs_end) > @@ -118,6 +123,21 @@ 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/psci.h> > + > +static int enable_psci_bp_hardening(void *data) > +{ > + const struct arm64_cpu_capabilities *entry = data; > + > + if (psci_ops.get_version) > + 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) \ > @@ -261,6 +281,28 @@ const struct arm64_cpu_capabilities arm64_errata[] = { > MIDR_ALL_VERSIONS(MIDR_CORTEX_A73), > }, > #endif > +#ifdef CONFIG_HARDEN_BRANCH_PREDICTOR > + { > + .capability = ARM64_HARDEN_BRANCH_PREDICTOR, > + MIDR_ALL_VERSIONS(MIDR_CORTEX_A57), > + .enable = enable_psci_bp_hardening, > + }, > + { > + .capability = ARM64_HARDEN_BRANCH_PREDICTOR, > + MIDR_ALL_VERSIONS(MIDR_CORTEX_A72), > + .enable = enable_psci_bp_hardening, > + }, > + { > + .capability = ARM64_HARDEN_BRANCH_PREDICTOR, > + MIDR_ALL_VERSIONS(MIDR_CORTEX_A73), > + .enable = enable_psci_bp_hardening, > + }, > + { > + .capability = ARM64_HARDEN_BRANCH_PREDICTOR, > + MIDR_ALL_VERSIONS(MIDR_CORTEX_A75), > + .enable = enable_psci_bp_hardening, > + }, > +#endif > { > } > }; On ThunderX2, we would like to do something similar, but it is important to find out if the current firmware has support for BTB invalidate in the PSCI version call. Otherwise, we will end up doing version calls that do nothing but return version (and waste cycles). I will follow up with ThunderX2 patches, but it would be good to have a standard way of figuring out if the firmware has BTB invalidate support. JC.
diff --git a/arch/arm64/kernel/bpi.S b/arch/arm64/kernel/bpi.S index 06a931eb2673..2e9146534174 100644 --- a/arch/arm64/kernel/bpi.S +++ b/arch/arm64/kernel/bpi.S @@ -53,3 +53,27 @@ ENTRY(__bp_harden_hyp_vecs_start) vectors __kvm_hyp_vector .endr ENTRY(__bp_harden_hyp_vecs_end) +ENTRY(__psci_hyp_bp_inval_start) + sub sp, sp, #(8 * 18) + stp x16, x17, [sp, #(16 * 0)] + stp x14, x15, [sp, #(16 * 1)] + stp x12, x13, [sp, #(16 * 2)] + stp x10, x11, [sp, #(16 * 3)] + stp x8, x9, [sp, #(16 * 4)] + stp x6, x7, [sp, #(16 * 5)] + stp x4, x5, [sp, #(16 * 6)] + stp x2, x3, [sp, #(16 * 7)] + stp x0, x1, [sp, #(18 * 8)] + mov x0, #0x84000000 + smc #0 + ldp x16, x17, [sp, #(16 * 0)] + ldp x14, x15, [sp, #(16 * 1)] + ldp x12, x13, [sp, #(16 * 2)] + ldp x10, x11, [sp, #(16 * 3)] + ldp x8, x9, [sp, #(16 * 4)] + ldp x6, x7, [sp, #(16 * 5)] + ldp x4, x5, [sp, #(16 * 6)] + ldp x2, x3, [sp, #(16 * 7)] + ldp x0, x1, [sp, #(18 * 8)] + add sp, sp, #(8 * 18) +ENTRY(__psci_hyp_bp_inval_end) diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c index 16ea5c6f314e..cb0fb3796bb8 100644 --- a/arch/arm64/kernel/cpu_errata.c +++ b/arch/arm64/kernel/cpu_errata.c @@ -53,6 +53,8 @@ static int cpu_enable_trap_ctr_access(void *__unused) DEFINE_PER_CPU_READ_MOSTLY(struct bp_hardening_data, bp_hardening_data); #ifdef CONFIG_KVM +extern char __psci_hyp_bp_inval_start[], __psci_hyp_bp_inval_end[]; + static void __copy_hyp_vect_bpi(int slot, const char *hyp_vecs_start, const char *hyp_vecs_end) { @@ -94,6 +96,9 @@ static void __install_bp_hardening_cb(bp_hardening_cb_t fn, spin_unlock(&bp_lock); } #else +#define __psci_hyp_bp_inval_start NULL +#define __psci_hyp_bp_inval_end NULL + static void __install_bp_hardening_cb(bp_hardening_cb_t fn, const char *hyp_vecs_start, const char *hyp_vecs_end) @@ -118,6 +123,21 @@ 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/psci.h> + +static int enable_psci_bp_hardening(void *data) +{ + const struct arm64_cpu_capabilities *entry = data; + + if (psci_ops.get_version) + 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) \ @@ -261,6 +281,28 @@ const struct arm64_cpu_capabilities arm64_errata[] = { MIDR_ALL_VERSIONS(MIDR_CORTEX_A73), }, #endif +#ifdef CONFIG_HARDEN_BRANCH_PREDICTOR + { + .capability = ARM64_HARDEN_BRANCH_PREDICTOR, + MIDR_ALL_VERSIONS(MIDR_CORTEX_A57), + .enable = enable_psci_bp_hardening, + }, + { + .capability = ARM64_HARDEN_BRANCH_PREDICTOR, + MIDR_ALL_VERSIONS(MIDR_CORTEX_A72), + .enable = enable_psci_bp_hardening, + }, + { + .capability = ARM64_HARDEN_BRANCH_PREDICTOR, + MIDR_ALL_VERSIONS(MIDR_CORTEX_A73), + .enable = enable_psci_bp_hardening, + }, + { + .capability = ARM64_HARDEN_BRANCH_PREDICTOR, + MIDR_ALL_VERSIONS(MIDR_CORTEX_A75), + .enable = enable_psci_bp_hardening, + }, +#endif { } };