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

[Szabolcs Nagy <szabolcs.nagy@arm.com>]

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.