[PATCH] arm64: errata: add workaround for cortex-a53 erratum #845719

[PATCH] arm64: errata: add workaround for cortex-a53 erratum #845719

[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.

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.

Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
Tested-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
 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(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 1b8e97331ffb..11103853d5f4 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -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
 
 
diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
index b6c16d5f622f..3f0c53c45771 100644
--- a/arch/arm64/include/asm/cpufeature.h
+++ b/arch/arm64/include/asm/cpufeature.h
@@ -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__
 
diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
index fa62637e63a8..ac5d965f1300 100644
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c
@@ -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
 	{
 	}
 };
diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
index cf21bb3bf752..959fe8733560 100644
--- a/arch/arm64/kernel/entry.S
+++ b/arch/arm64/kernel/entry.S
@@ -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
-- 
2.1.4

[PATCH] arm64: errata: add workaround for cortex-a53 erratum #845719

[Kevin Hilman]

Hi Will,

On Tue, Mar 31, 2015 at 2:08 AM, Will Deacon <will.deacon@arm.com> wrote:
> 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.
>
> Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
> Tested-by: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Will Deacon <will.deacon@arm.com>

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] arm64: errata: add workaround for cortex-a53 erratum #845719

[Will Deacon]

On Wed, Apr 22, 2015 at 08:37:27PM +0100, Kevin Hilman wrote:
> Hi Will,

Hi Kevin,

> On Tue, Mar 31, 2015 at 2:08 AM, Will Deacon <will.deacon@arm.com> wrote:
> > 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.
> >
> > Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
> > Tested-by: Mark Rutland <mark.rutland@arm.com>
> > Signed-off-by: Will Deacon <will.deacon@arm.com>
> 
> 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.

> 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.

> 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] arm64: errata: add workaround for cortex-a53 erratum #845719

[Kevin Hilman]

Will Deacon <will.deacon@arm.com> writes:

>> On Tue, Mar 31, 2015 at 2:08 AM, Will Deacon <will.deacon@arm.com> wrote:
>> > 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.
>> >
>> > Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
>> > Tested-by: Mark Rutland <mark.rutland@arm.com>
>> > Signed-off-by: Will Deacon <will.deacon@arm.com>
>> 
>> 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.

>> 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.

>> 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.

> 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