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

[Szabolcs Nagy via Libc-alpha <libc-alpha@sourceware.org>]

The 08/12/2021 10:36, Florian Weimer wrote:
> * H. J. Lu:
> > +@deftypefun int set_tagged_address_mask (uintptr_t @var{mask})
> > +@standards{GNU, sys/tagged-address.h}
> > +@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
> > +Set the mask for address bits used in address translation to @var{mask}.
> > +Only bits set in @var{mask} will be used in address translation.  The
> > +return value is @code{0} on success and @code{-1} on failure.  This
> > +function can be called only once before @code{main}.
> 
> Again the restriction around @code{main} is unclear.  If it's “before
> allocating memory” or “before starting threads”, than we should say
> that.

it should be at least before thread creation on aarch64.

> I still don't see a way how we can split tag address bits used by the
> implementation (glibc, sanitizers) and the application.

an application may not be able to use tag bits at all:

+All pointers participating in a pointer arithmetic operation should have
+the same tag if they point to the same memory object so that pointer
+equality operation can be performed on tagged pointers.

if the implementation gives an untagged pointer to user code
which tags it then there are differently tagged pointers to
the same object: 0 tag and user tag. it is generally hard to
ensure that pointers don't escape and don't end up breaking
pointer cmp somewhere.

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)

another approach is to allow user tags and user has to deal
with potential problems (requiring compiler barriers around
pointer tagging etc), in that case i think we have to reserve
bits for the implementation if we want to use that for malloc.