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

["H.J. Lu" <hjl.tools@gmail.com>]

On Thu, Feb 18, 2021 at 5:50 AM Szabolcs Nagy <szabolcs.nagy@arm.com> wrote:
>
> The 02/18/2021 14:28, Florian Weimer wrote:
> > * Szabolcs Nagy:
> > >> was called in a thread.  It won't work when 2 threads have different address
> > >> masks.  I think set_tagged_address_mask should be disallowed in child
> > >> threads and in parent thread when there are any active child threads.
> > >
> > > i think this is the wrong api. currently the libc should set
> > > things up early. api for user code is too late.
> > >
> > > user code does not know if it runs single threaded or not
> > > (although we have __libc_single_threaded now, i'm not sure if
> > > we can use that for this purpose)
> >
> > We could, but it's possible to launch threads from ELF constructors (and
> > I think some libraries do that).  So you could avoid the call or
> > diagnose a failure if single-threaded, but the tagged address feature
> > wouldn't compose well.
> >
> > Some kernel interfaces have this problem (e.g., unshare), but they are
> > less general-purpose than tagged addresses.
>
> it is possible to have a prctl flag that requests the abi
> change for the entire process. (and then the kernel has
> to do the sync across threads.)
>
> the semantics is not entirely obvious wrt memory model
> if we want to do this for e.g. MTE tag checks, but for
> syscall abi it should be possible to define reasonably.
>
> e.g. a use-case for changing mte/tag abi settings for an
> entire process is a custom allocator that wants to use
> heap tagging. by the time it can call the prctl the
> process may be already multi-threaded.
>
> there is also a problem with coordination between
> concurrent callers. this is simple with the tagged
> address abi which is a 1 bit state and we can say that
> it always goes one way: no tag -> tag, but more complex
> state like mte checking mode or mte tag exclusion set,
> requires coordination, which tells me that there should
> be a single owner: the libc.
>
> but i don't know what requirements intel LAM has.

We are working to enable LAM in glibc and GCC (HWASAN).

0. LAM is disabled when the process starts.
1. Define GNU property markers for LAM compatibility.
2. Update ld.so to support LAM.
3. Make libc.so LAM compatible (memmove).
4. Provide an API to enable LAM.

We noticed a few issues:

1. HWASAN should use the glibc API to enable tagged address
since glibc must track the tagged address mask.
2. set_tagged_address_mask shouldn't be allowed after
pthread_create is called.
3. After set_tagged_address_mask is called, can it be called
again to change tagged address mask.

-- 
H.J.