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 Thu, Aug 12, 2021 at 5:01 AM Szabolcs Nagy <szabolcs.nagy@arm.com> wrote:
>
> 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.

Before main is before thread creation and before main is safer
than before thread creation.

> > 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.

Tag usage must be exclusive for malloc or HWASAN.   malloc
usage must be checked at run-time for

1. Is tag enabled? And
2. Is tag used for another purpose?

If tag isn't enabled or used for another purpose, malloc should
avoid using tag.   This API can inform glibc that an user code
is requesting tag usage.

-- 
H.J.