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

[Szabolcs Nagy]

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.

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.

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.