Use the original FAR_EL1 value when an MTE tag check fault occurs,
if ARM64_MTE_FAR is supported.
This allows reports to include not only the logical tag (memory tag)
but also the address tag information.

Applications that require this information should install a signal handler with
the SA_EXPOSE_TAGBITS flag.
While this introduces a minor ABI change,
most applications do not set this flag and therefore will not be affected.

Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
---
 arch/arm64/mm/fault.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index ec0a337891dd..f21d972f99b1 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -837,9 +837,12 @@ static int do_tag_check_fault(unsigned long far, unsigned long esr,
 	/*
 	 * The architecture specifies that bits 63:60 of FAR_EL1 are UNKNOWN
 	 * for tag check faults. Set them to corresponding bits in the untagged
-	 * address.
+	 * address if ARM64_MTE_FAR isn't supported.
+	 * Otherwise, bits 63:60 of FAR_EL1 are KNOWN.
 	 */
-	far = (__untagged_addr(far) & ~MTE_TAG_MASK) | (far & MTE_TAG_MASK);
+	if (!cpus_have_cap(ARM64_MTE_FAR))
+		far = (__untagged_addr(far) & ~MTE_TAG_MASK) | (far & MTE_TAG_MASK);
+
 	do_bad_area(far, esr, regs);
 	return 0;
 }
-- 
LEVI:{C3F47F37-75D8-414A-A8BA-3980EC8A46D7}

+ Peter Collingbourne as he added the SA_EXPOSE_TAGBITS flag.

On Thu, Apr 10, 2025 at 08:47:20AM +0100, Yeoreum Yun wrote:
> Use the original FAR_EL1 value when an MTE tag check fault occurs,
> if ARM64_MTE_FAR is supported.
> This allows reports to include not only the logical tag (memory tag)
> but also the address tag information.
> 
> Applications that require this information should install a signal handler with
> the SA_EXPOSE_TAGBITS flag.
> While this introduces a minor ABI change,
> most applications do not set this flag and therefore will not be affected.

It is indeed a minor ABI in that a tag check fault resulting in a
signal will report the bits 63:60 as well, not just 59:56 of the address
(if the signal handler was registered with SA_EXPOSE_TAGBITS).

I don't think user-space would notice but asking Peter.

> Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
> ---
>  arch/arm64/mm/fault.c | 7 +++++--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
> index ec0a337891dd..f21d972f99b1 100644
> --- a/arch/arm64/mm/fault.c
> +++ b/arch/arm64/mm/fault.c
> @@ -837,9 +837,12 @@ static int do_tag_check_fault(unsigned long far, unsigned long esr,
>  	/*
>  	 * The architecture specifies that bits 63:60 of FAR_EL1 are UNKNOWN
>  	 * for tag check faults. Set them to corresponding bits in the untagged
> -	 * address.
> +	 * address if ARM64_MTE_FAR isn't supported.
> +	 * Otherwise, bits 63:60 of FAR_EL1 are KNOWN.
>  	 */
> -	far = (__untagged_addr(far) & ~MTE_TAG_MASK) | (far & MTE_TAG_MASK);
> +	if (!cpus_have_cap(ARM64_MTE_FAR))
> +		far = (__untagged_addr(far) & ~MTE_TAG_MASK) | (far & MTE_TAG_MASK);
> +
>  	do_bad_area(far, esr, regs);
>  	return 0;
>  }
> -- 
> LEVI:{C3F47F37-75D8-414A-A8BA-3980EC8A46D7}

On Fri, May 2, 2025 at 10:08 AM Catalin Marinas <catalin.marinas@arm.com> wrote:
>
> + Peter Collingbourne as he added the SA_EXPOSE_TAGBITS flag.
>
> On Thu, Apr 10, 2025 at 08:47:20AM +0100, Yeoreum Yun wrote:
> > Use the original FAR_EL1 value when an MTE tag check fault occurs,
> > if ARM64_MTE_FAR is supported.
> > This allows reports to include not only the logical tag (memory tag)
> > but also the address tag information.
> >
> > Applications that require this information should install a signal handler with
> > the SA_EXPOSE_TAGBITS flag.
> > While this introduces a minor ABI change,
> > most applications do not set this flag and therefore will not be affected.
>
> It is indeed a minor ABI in that a tag check fault resulting in a
> signal will report the bits 63:60 as well, not just 59:56 of the address
> (if the signal handler was registered with SA_EXPOSE_TAGBITS).
>
> I don't think user-space would notice but asking Peter.

On Android we don't set bits 63:60 on heap addresses when MTE is
enabled (and userspace programs aren't allowed to modify them in
addresses they get back from the heap allocator either) so the fault
handler should continue to see them as 0. Of course, a userspace
program could be breaking the rules and setting those bits anyway, but
in that case it looks like the only consequence would be that the
error reports from the heap allocator would sometimes be missing some
information (and this could already happen if the access results in a
non-MTE fault) which I think is acceptable.

Peter

>
> > Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
> > ---
> >  arch/arm64/mm/fault.c | 7 +++++--
> >  1 file changed, 5 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
> > index ec0a337891dd..f21d972f99b1 100644
> > --- a/arch/arm64/mm/fault.c
> > +++ b/arch/arm64/mm/fault.c
> > @@ -837,9 +837,12 @@ static int do_tag_check_fault(unsigned long far, unsigned long esr,
> >       /*
> >        * The architecture specifies that bits 63:60 of FAR_EL1 are UNKNOWN
> >        * for tag check faults. Set them to corresponding bits in the untagged
> > -      * address.
> > +      * address if ARM64_MTE_FAR isn't supported.
> > +      * Otherwise, bits 63:60 of FAR_EL1 are KNOWN.
> >        */
> > -     far = (__untagged_addr(far) & ~MTE_TAG_MASK) | (far & MTE_TAG_MASK);
> > +     if (!cpus_have_cap(ARM64_MTE_FAR))
> > +             far = (__untagged_addr(far) & ~MTE_TAG_MASK) | (far & MTE_TAG_MASK);
> > +
> >       do_bad_area(far, esr, regs);
> >       return 0;
> >  }
> > --
> > LEVI:{C3F47F37-75D8-414A-A8BA-3980EC8A46D7}

Hi Peter,

> On Fri, May 2, 2025 at 10:08 AM Catalin Marinas <catalin.marinas@arm.com> wrote:
> >
> > + Peter Collingbourne as he added the SA_EXPOSE_TAGBITS flag.
> >
> > On Thu, Apr 10, 2025 at 08:47:20AM +0100, Yeoreum Yun wrote:
> > > Use the original FAR_EL1 value when an MTE tag check fault occurs,
> > > if ARM64_MTE_FAR is supported.
> > > This allows reports to include not only the logical tag (memory tag)
> > > but also the address tag information.
> > >
> > > Applications that require this information should install a signal handler with
> > > the SA_EXPOSE_TAGBITS flag.
> > > While this introduces a minor ABI change,
> > > most applications do not set this flag and therefore will not be affected.
> >
> > It is indeed a minor ABI in that a tag check fault resulting in a
> > signal will report the bits 63:60 as well, not just 59:56 of the address
> > (if the signal handler was registered with SA_EXPOSE_TAGBITS).
> >
> > I don't think user-space would notice but asking Peter.
>
> On Android we don't set bits 63:60 on heap addresses when MTE is
> enabled (and userspace programs aren't allowed to modify them in
> addresses they get back from the heap allocator either) so the fault
> handler should continue to see them as 0. Of course, a userspace
> program could be breaking the rules and setting those bits anyway, but
> in that case it looks like the only consequence would be that the
> error reports from the heap allocator would sometimes be missing some
> information (and this could already happen if the access results in a
> non-MTE fault) which I think is acceptable.
>
> Peter

Thanks for your confirmation :)

--
Sincerely,
Yeoreum Yun