When booting the kernel we access system registers such as GCR_EL1
if MTE is supported. These accesses are defined to trap to EL3 if
SCR_EL3.ATA is disabled. Furthermore, tag accesses will not behave
as expected if SCR_EL3.ATA is not set, or if HCR_EL2.ATA is not set
and we were booted at EL1. Therefore, require that these bits are
enabled when appropriate.
Signed-off-by: Peter Collingbourne <[email protected]>
Link: https://linux-review.googlesource.com/id/Iadcfd4dcd9ba3279b2813970b44d7485b0116709
---
Documentation/arm64/booting.rst | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/Documentation/arm64/booting.rst b/Documentation/arm64/booting.rst
index 29884b261aa9..833af981b667 100644
--- a/Documentation/arm64/booting.rst
+++ b/Documentation/arm64/booting.rst
@@ -350,6 +350,16 @@ Before jumping into the kernel, the following conditions must be met:
- SMCR_EL2.FA64 (bit 31) must be initialised to 0b1.
+ For CPUs with the Memory Tagging Extension feature:
+
+ - If EL3 is present:
+
+ - SCR_EL3.ATA (bit 26) must be initialised to 0b1.
+
+ - If the kernel is entered at EL1 and EL2 is present:
+
+ - HCR_EL2.ATA (bit 56) must be initialised to 0b1.
+
The requirements described above for CPU mode, caches, MMUs, architected
timers, coherency and system registers apply to all CPUs. All CPUs must
enter the kernel in the same exception level. Where the values documented
--
2.35.1.1094.g7c7d902a7c-goog
On Mon, Apr 04, 2022 at 02:18:58PM -0700, Peter Collingbourne wrote:
> + For CPUs with the Memory Tagging Extension feature:
> +
> + - If EL3 is present:
> +
> + - SCR_EL3.ATA (bit 26) must be initialised to 0b1.
> +
> + - If the kernel is entered at EL1 and EL2 is present:
> +
> + - HCR_EL2.ATA (bit 56) must be initialised to 0b1.
Very nitpicky but this is only required for FEAT_MTE2 and above, plain
FEAT_MTE doesn't have these traps. I don't know that this is a thing
that anyone's actually implemented and from v8.7 on it's not permitted
but the above isn't strictly true if someone did for some reason have
the most basic version.
Otherwise
Reviewed-by: Mark Brown <[email protected]>
On Tue, Apr 05, 2022 at 09:04:04AM +0100, Mark Brown wrote:
> On Mon, Apr 04, 2022 at 02:18:58PM -0700, Peter Collingbourne wrote:
>
> > + For CPUs with the Memory Tagging Extension feature:
> > +
> > + - If EL3 is present:
> > +
> > + - SCR_EL3.ATA (bit 26) must be initialised to 0b1.
> > +
> > + - If the kernel is entered at EL1 and EL2 is present:
> > +
> > + - HCR_EL2.ATA (bit 56) must be initialised to 0b1.
>
> Very nitpicky but this is only required for FEAT_MTE2 and above, plain
> FEAT_MTE doesn't have these traps. I don't know that this is a thing
> that anyone's actually implemented
I think that's a valid point. CPUs may implement FEAT_MTE2 but downgrade
it to FEAT_MTE if the SoC does not provide allocation tag storage. So we
should make it clear here that only from FEAT_MTE2 we should set those
bits (ID_AA64PFR1_EL1.MTE >= 2), otherwise they should be 0 or
hyp/firmware risks the OS triggering random external aborts.
> and from v8.7 on it's not permitted but the above isn't strictly true
> if someone did for some reason have the most basic version.
The wording is tricky: "This feature is mandatory from Armv8.7 when
FEAT_MTE2 is implemented". So one can still implement FEAT_MTE (or none
at all).
--
Catalin
On Fri, Apr 22, 2022 at 6:42 AM Catalin Marinas <[email protected]> wrote:
>
> On Tue, Apr 05, 2022 at 09:04:04AM +0100, Mark Brown wrote:
> > On Mon, Apr 04, 2022 at 02:18:58PM -0700, Peter Collingbourne wrote:
> >
> > > + For CPUs with the Memory Tagging Extension feature:
> > > +
> > > + - If EL3 is present:
> > > +
> > > + - SCR_EL3.ATA (bit 26) must be initialised to 0b1.
> > > +
> > > + - If the kernel is entered at EL1 and EL2 is present:
> > > +
> > > + - HCR_EL2.ATA (bit 56) must be initialised to 0b1.
> >
> > Very nitpicky but this is only required for FEAT_MTE2 and above, plain
> > FEAT_MTE doesn't have these traps. I don't know that this is a thing
> > that anyone's actually implemented
>
> I think that's a valid point. CPUs may implement FEAT_MTE2 but downgrade
> it to FEAT_MTE if the SoC does not provide allocation tag storage. So we
> should make it clear here that only from FEAT_MTE2 we should set those
> bits (ID_AA64PFR1_EL1.MTE >= 2), otherwise they should be 0 or
> hyp/firmware risks the OS triggering random external aborts.
>
> > and from v8.7 on it's not permitted but the above isn't strictly true
> > if someone did for some reason have the most basic version.
>
> The wording is tricky: "This feature is mandatory from Armv8.7 when
> FEAT_MTE2 is implemented". So one can still implement FEAT_MTE (or none
> at all).
Okay, I changed it in v2 to explicitly say FEAT_MTE2.
Peter