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

[Richard Earnshaw <Richard.Earnshaw@foss.arm.com>]

On 21/12/2020 13: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.
> 

I'm sure that there are several enhancements to these patches that are
possible and the above is just one of them.  I think they can be worked
on as follow ups.  The more hooks, however, the more performance impact
there is likely to be, even if it's just an extra indirect function call.

A limitation of the architecture is that, in effect, the tags used are
completely random (with no seed that can be used to get repeatability);
that's good from a security standpoint (avoids common-mode failures),
but makes things more difficult if you're trying to reproduce an issue
under a debugger.  I'm not sure how to address that either.

R.

> Thanks,
> Florian
>