This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFD - Support for memory tagging in GLIBC

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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]