linux-kernel - Re: [PATCH v3 2/3] arm64/mm/fault: use original FAR_EL1 value when ARM64_MTE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAMn1gO4Ft2R+_CN+XdTsO0YpUQZN7zShMSg-XT90U698Rnifjw@mail.gmail.com>
Date: Fri, 2 May 2025 11:25:01 -0700
From: Peter Collingbourne <pcc@...gle.com>
To: Catalin Marinas <catalin.marinas@....com>
Cc: Yeoreum Yun <yeoreum.yun@....com>, will@...nel.org, broonie@...nel.org, 
	anshuman.khandual@....com, joey.gouly@....com, yury.khrustalev@....com, 
	maz@...nel.org, oliver.upton@...ux.dev, frederic@...nel.org, 
	shmeerali.kolothum.thodi@...wei.com, james.morse@....com, 
	mark.rutland@....com, huangxiaojia2@...wei.com, akpm@...ux-foundation.org, 
	surenb@...gle.com, robin.murphy@....com, linux-arm-kernel@...ts.infradead.org, 
	linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org, nd@....com
Subject: Re: [PATCH v3 2/3] arm64/mm/fault: use original FAR_EL1 value when
 ARM64_MTE_FAR is supported

On Fri, May 2, 2025 at 10:08 AM Catalin Marinas <catalin.marinas@....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@....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}