Re: [PATCH v5 1/1] <sys/tagged-address.h>: An API for tagged address

["H.J. Lu via Libc-alpha" <libc-alpha@sourceware.org>]

On Tue, Aug 17, 2021 at 8:00 AM Szabolcs Nagy <szabolcs.nagy@arm.com> wrote:
>
> The 08/17/2021 05:53, H.J. Lu via Libc-alpha wrote:
> > On Tue, Aug 17, 2021 at 5:33 AM Szabolcs Nagy via Libc-alpha
> > <libc-alpha@sourceware.org> wrote:
> > >
> > > The 08/12/2021 13:01, Szabolcs Nagy via Libc-alpha wrote:
> > > > The 08/12/2021 10:36, Florian Weimer wrote:
> > > > > I still don't see a way how we can split tag address bits used by the
> > > > > implementation (glibc, sanitizers) and the application.
> > > ...
> > > > so one approach is to just disallow user tags, only sanitizer
> > > > and similar tools can tag (and i think hwasan can coordinate
> > > > with glibc via less formal api/abi that we can change later)
> > >
> > > to expand on this: i think we should just focus on the hwasan
> > > use-case. there may be other use-cases for tagged addresses,
> > > but we need more experience before we can design a generic api.
> > > hwasan can just poke at implementation internals and have
> > > target specific logic for now.
> >
> > Agreed.  My motivation is hwasan.
> >
> > > allowing application code to use the tag bits can break c
> > > semantics and compiler assumptions too easily.
> > >
> > > and we should not require hwasan to use libc apis to work
> > > with tagged addresses, that would slow it down.
> >
> > There is no reason why a libc API should be slow.   Currently,
> > LAM enabled libsanitizer/hwasan has
> >
> > #include <sys/tagged-address.h>
> >
> > bool lam_failed = set_tagged_address_mask (TAGGED_ADDRESS_MASK (57))
> >
> > We only need this function to enable LAM in libsanitizer/hwasan
> > and inform glibc that LAM is enabled.  The rest of functions in
> > <sys/tagged-address.h> are used to make memmove and memmove
> > tests LAM compatible.  We can move them to internal header files.
>
> ok.
>
> libc internal api is a different story, i thought you
> expect hwasan to use tag_address, get_tagged_address_mask
> etc and that would affect hwasan code gen.

They are not used in the current implementation of LAM-enabled hwasan.

> if that's not the case then i don't think these apis should
> be exposed.
>
> > > so i think we don't need the tagged address representation
> > > related apis. we may need something __hwasan_init can call
> > > to set up os support. on aarch64 that's a prctl now, but a
> > > libc api would allow us to disable hwasan from glibc (e.g.
> > > if there are elf markings for incompatible dsos), i don't
> >
> > set_tagged_address_mask can be used to enable and disable
> > LAM/TBI.  memmove needs to know if LAM/TBI is enabled or not
> > to work correctly.
>
> i'm not convinced memmove needs to know.

memmove may not need to know LAM bits for hwasn.  But memmove
needs to know if LAM is enabled in general.

> if hwasan tags memory more fine grained than what is
> passed to memmove as single object then there can be
> issues in user code too with pointer diff calculations
> within that object.
>
> > > know if that makes sense (does hwasan have a fall back if
> > > there is no os support?).
> > >
> >
> > It is a hard error for hwasan if LAM/TBI isn't available.
> >
> > Thanks.
>
> i see.



--
H.J.