arm64: errata: add workaround for cortex-a53 erratum #845719
PATCH 1/1 arm64: errata: add workaround for cortex-a53 erratum #845719
When running a compat (AArch32) userspace on Cortex-A53, a load at EL0 from a virtual address that matches the bottom 32 bits of the virtual address used by a recent load at (AArch64) EL1 might return incorrect data.
This patch works around the issue by writing to the contextidr_el1 register on the exception return path when returning to a 32-bit task. This workaround is patched in at runtime based on the MIDR value of the processor.
--- arch/arm64/Kconfig | 21 +++++++++++++++++++++ arch/arm64/include/asm/cpufeature.h | 3 ++- arch/arm64/kernel/cpu_errata.c | 8 ++++++++ arch/arm64/kernel/entry.S | 20 ++++++++++++++++++++ 4 files changed, 51 insertions(+), 1 deletion(-)
arch/arm64/Kconfig +21 -0
@@ -361,6 +361,27 @@ config ARM64_ERRATUM_832075 If unsure, say Y. +config ARM64_ERRATUM_845719 + bool "Cortex-A53: 845719: a load might read incorrect data" + depends on COMPAT + default y + help + This option adds an alternative code sequence to work around ARM + erratum 845719 on Cortex-A53 parts up to r0p4. + + When running a compat (AArch32) userspace on an affected Cortex-A53 + part, a load at EL0 from a virtual address that matches the bottom 32 + bits of the virtual address used by a recent load at (AArch64) EL1 + might return incorrect data. + + The workaround is to write the contextidr_el1 register on exception + return to a 32-bit task. + Please note that this does not necessarily enable the workaround, + as it depends on the alternative framework, which will only patch + the kernel if an affected CPU is detected. + + If unsure, say Y. + endmenu
arch/arm64/include/asm/cpufeature.h +2 -1
@@ -23,8 +23,9 @@#define ARM64_WORKAROUND_CLEAN_CACHE 0#define ARM64_WORKAROUND_DEVICE_LOAD_ACQUIRE 1 +#define ARM64_WORKAROUND_845719 2 -#define ARM64_NCAPS 2 +#define ARM64_NCAPS 3#ifndef __ASSEMBLY__
arch/arm64/kernel/cpu_errata.c +8 -0
@@ -91,6 +91,14 @@ struct arm64_cpu_capabilities arm64_errata[] = { MIDR_RANGE(MIDR_CORTEX_A57, 0x00, 0x12), },#endif +#ifdef CONFIG_ARM64_ERRATUM_845719 + { +/* Cortex-A53 r0p[01234] */ + .desc = "ARM erratum 845719", + .capability = ARM64_WORKAROUND_845719, + MIDR_RANGE(MIDR_CORTEX_A53, 0x00, 0x04), + }, +#endif { } };
arch/arm64/kernel/entry.S +20 -0
@@ -21,8 +21,10 @@ #include <linux/init.h> #include <linux/linkage.h> +#include <asm/alternative-asm.h> #include <asm/assembler.h> #include <asm/asm-offsets.h> +#include <asm/cpufeature.h> #include <asm/errno.h> #include <asm/esr.h> #include <asm/thread_info.h>
@@ -120,6 +122,24 @@ ct_user_enter ldr x23, [sp, #S_SP] // load return stack pointer msr sp_el0, x23 + +#ifdef CONFIG_ARM64_ERRATUM_845719 + alternative_insn \ + "nop", \ + "tbz x22, #4, 1f", \ + ARM64_WORKAROUND_845719 +#ifdef CONFIG_PID_IN_CONTEXTIDR + alternative_insn \ + "nop; nop", \ + "mrs x29, contextidr_el1; msr contextidr_el1, x29; 1:", \ + ARM64_WORKAROUND_845719 +#else + alternative_insn \ + "nop", \ + "msr contextidr_el1, xzr; 1:", \ + ARM64_WORKAROUND_845719 +#endif +#endif .endif msr elr_el1, x21 // set up the return data msr spsr_el1, x22
Signature · 1 line
2.1.4
PATCH 1/1 arm64: errata: add workaround for cortex-a53 erratum #845719
Hi Will,
Quoted 5 lines · Will Deacon
When running a compat (AArch32) userspace on Cortex-A53, a load at EL0 from a virtual address that matches the bottom 32 bits of the virtual address used by a recent load at (AArch64) EL1 might return incorrect data.
Quoted 8 lines
This patch works around the issue by writing to the
contextidr_el1register on the exception return path when returning to a 32-bit task. This workaround is patched in at runtime based on the MIDR value of the processor.Reviewed-by Marc Zyngier <[email protected]>Tested-by Mark Rutland <[email protected]>Signed-off-by Will Deacon <[email protected]>
Curious if you are planning to flag this for v3.19-stable? I also noticed that the recent one from Bo Yan[1] for A57 might also be missing from stable/linux-3.19.y. A quick check suggests they both apply cleanly to stable/linux-3.19.y
Speaking of stable, is anyone at ARM working on getting these into older versions of stable?
For v3.18, I did a quick backport (and simple boot test on qemu) of Andre's framework plus the errata I'm aware of to stable/linux-3.18.y, and it seems to work (kernel reports "alternative: enabling workaround for ARM erratum 832075) so getting the framework plus errata into stable/linux-3.18.y seems like a good idea too and pretty straight forward too.
Kevin
[1] commit 6d1966dfd6e0 (arm64: fix midr range for Cortex-A57 erratum 832075)
[2] git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux.git
wip/v3.18/arm64-errata
PATCH 1/1 arm64: errata: add workaround for cortex-a53 erratum #845719
Quoted 1 line · Kevin Hilman
Hi Will,
Hi Kevin,
Quoted 11 lines · Will Deacon
Quoted 10 lines
When running a compat (AArch32) userspace on Cortex-A53, a load at EL0 from a virtual address that matches the bottom 32 bits of the virtual address used by a recent load at (AArch64) EL1 might return incorrect data.
This patch works around the issue by writing to the
contextidr_el1register on the exception return path when returning to a 32-bit task. This workaround is patched in at runtime based on the MIDR value of the processor.
Quoted 8 lines
Quoted 3 lines
Reviewed-by Marc Zyngier <[email protected]>Tested-by Mark Rutland <[email protected]>Signed-off-by Will Deacon <[email protected]>Curious if you are planning to flag this for v3.19-stable? I also noticed that the recent one from Bo Yan[1] for A57 might also be missing from stable/linux-3.19.y. A quick check suggests they both apply cleanly to stable/linux-3.19.y
I wasn't planning on it, but if somebody wants it for 3.19 they could certainly send it to Greg.
Quoted 2 lines
Speaking of stable, is anyone at ARM working on getting these into older versions of stable?
No; although I was under the impression that Linaro had been tasked to do the backports for LSK.
Quoted 6 lines
For v3.18, I did a quick backport (and simple boot test on qemu) of Andre's framework plus the errata I'm aware of to stable/linux-3.18.y, and it seems to work (kernel reports "alternative: enabling workaround for ARM erratum 832075) so getting the framework plus errata into stable/linux-3.18.y seems like a good idea too and pretty straight forward too.
Backporting the entire alternatives framework to -stable sounds pretty heavyweight to me, particularly if we have to go back as far as 3.10. We could unconditionally backport the errata workarounds, but that would require us to assess the performance impact on a variety of CPUs for each of the backports, which I don't think is a good idea.
Will
PATCH 1/1 arm64: errata: add workaround for cortex-a53 erratum #845719
Quoted 15 lines · Will Deacon
Quoted 15 lines · Will Deacon
Quoted 13 lines
When running a compat (AArch32) userspace on Cortex-A53, a load at EL0 from a virtual address that matches the bottom 32 bits of the virtual address used by a recent load at (AArch64) EL1 might return incorrect data.
This patch works around the issue by writing to the
contextidr_el1register on the exception return path when returning to a 32-bit task. This workaround is patched in at runtime based on the MIDR value of the processor.Reviewed-by Marc Zyngier <[email protected]>Tested-by Mark Rutland <[email protected]>Signed-off-by Will Deacon <[email protected]>
Quoted 7 lines
Quoted 4 lines
Curious if you are planning to flag this for v3.19-stable? I also noticed that the recent one from Bo Yan[1] for A57 might also be missing from stable/linux-3.19.y. A quick check suggests they both apply cleanly to stable/linux-3.19.y
I wasn't planning on it, but if somebody wants it for 3.19 they could certainly send it to Greg.
OK, I'll take care of that.
Quoted 5 lines
Quoted 2 lines
Speaking of stable, is anyone at ARM working on getting these into older versions of stable?
No; although I was under the impression that Linaro had been tasked to do the backports for LSK.
Exactly why I'm asking. The preferred path for LSK is via the stable tree, so I'd like to see them there first if at all possible.
Quoted 9 lines
Quoted 6 lines
For v3.18, I did a quick backport (and simple boot test on qemu) of Andre's framework plus the errata I'm aware of to stable/linux-3.18.y, and it seems to work (kernel reports "alternative: enabling workaround for ARM erratum 832075) so getting the framework plus errata into stable/linux-3.18.y seems like a good idea too and pretty straight forward too.
Backporting the entire alternatives framework to -stable sounds pretty heavyweight to me, particularly if we have to go back as far as 3.10.
3.18 was very straighforward, direct cherry-picks worked cleanly, so I'm thinking of sending that series to stable as well.
But your right, further back gets a bit more cumbersome. So far, I've manged to do it for 3.14[1] with a bit more headaches, but it's not too bad. The other LSK is 3.10, and it's probably going to be quite a bit more headache. IMO neither 3.14 or 3.10 is probably a good candidate to send to stable, so may end up being LSK only.
That being said, I'd still like to see future errata show up in stable for at least >= v3.18, since it will be easy to do.
Quoted 3 lines
We could unconditionally backport the errata workarounds, but that would require us to assess the performance impact on a variety of CPUs for each of the backports, which I don't think is a good idea.
Any other suggestions? Maybe simple compile-time ifdefs for 3.10 will be simplest.
Kevin
[1] git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux.git wip/v3.14/arm64-errata