[PATCH v4 3/6] malloc: Basic support for memory tagging in the malloc() family

[Szabolcs Nagy]

The 12/21/2020 14:46, Florian Weimer via Libc-alpha wrote:
> * Richard Earnshaw via Libc-alpha:
> > +/* Generate a new (random) tag value for PTR, set the tags for the
> > +   memory to the new tag and initialize the memory contents to VAL.
> > +   In practice this function will only be called with VAL=0, but we
> > +   keep this parameter to maintain the same prototype as memset.  */
> > +static void *
> > +__mtag_tag_new_memset (void *ptr, int val, size_t size)
> > +{
> > +  return __libc_mtag_memset_with_tag (__libc_mtag_new_tag (ptr), val, size);
> > +}
> 
> I would like to point out that random choice from all possible tag bits
> precludes some memory tagging applications.  Some applications might
> want to unconditionally force certain tag bits on a load, to assert that
> the pointer refers to a specific kind of memory.  If glibc malloc
> randomly assigns tag bits from entire range, this kind of memory type
> assertion is no longer eliable.

in the mte architecture we can control the set of tags
__libc_mtag_new_tag (irg instruction) may select from.

currently we set the MTE_ALLOWED_TAGS in aarch64 via
prctl such that all tags are allowed except 0.

i imagine if we have a usecase for using specific tags
somewhere then we would exclude those from the allowed
random tags.

(e.g. malloc metadata in heap memory is 0 tagged now
which is guaranteed to be different from the user
allocation tags, but we could reserve a special tag
for metadata and exclude that from the allowed tags.)

note that currently user code cannot easily use tagging:
the prctl settings are owned by the libc and cannot be
changed easily in a multithreaded process. suballocators
cannot retag heap memory unless they revert the tags
before calling free. and the PROT_MTE setting for most
variables are libc controlled (globals in elf objects
heap and stack). so only manually mmaped memory can use
tags in user code. we could reserve some tags for such
usage that are distinct from heap tags, but havent so
far.

since we haven't committed to a stable abi yet with the
tunables i think we have opportunity to change this if
necessary.