Re: RFD - Support for memory tagging in GLIBC

[Paul Eggert <eggert at cs dot ucla dot edu>]

Thanks for the heads-up on this. Some questions:

If I build an app with the proposed glibc, can I run it with memory tagging 
disabled even if the hardware supports memory tagging? If so, will malloc etc. 
behave differently (e.g., return different addresses) depending on whether 
memory tagging is enabled? That might make debugging harder.

What's the application model when a program violates the memory tagging rules? 
Presumably it gets a SIGSEGV; what sort of si_codes does it get? etc. This would 
need documentation, presumably.

Could you elaborate a bit on how the proposed work relates to SPARC ADI, support 
for which is in the Linux kernel? For example, would the differences between the 
two memory-tagging architectures be visible to the application?

I know you weren't asking for detailed code comments, but a couple things anyway:

> +  bytes = ROUND_UP_ALLOCATION_SIZE (bytes);

This misfires if bytes == SIZE_MAX.

> +  /* Quickly check that the freed pointer matches the tag for the memory.
> +     This gives a useful double-free detection.  */
> +  *(volatile char *)mem;

Wouldn't it be safer to check all the storage that the freed pointer addresses? 
Although O(size) rather than O(1), with MTE free is O(size) anyway so....

> +  /* If we are using memory tagging, then we need to set the tags
> +     regardless of MORECORE_CLEARS, so we zero the whole block while
> +     doing so.  */

Should there be a MORECORE_TAGS? That is, the morecore primitive might be able 
to tag for us just as it clears for us.