Conversation

I'm curious to learn how memory safety features like memory tagging affect development techniques/practices.
Quote Tweet
I've put a lot of time into the design and implementation, with the approach informed by allocators like OpenBSD malloc, DieHard(er), PartitionAlloc and jemalloc in various ways. It's primarily designed around deterministic defences, and with features like memory tagging in mind.
Show this thread
1
Replying to
In github.com/GrapheneOS/har, you can see how the integration is planned for hardened_malloc. In terms of application / library code, using memory tagging for stack frame / variable protection will create performance pressure to stop putting large, oversized buffers on the stack.
1
Replying to and
For malloc in general, the costs of memory tagging should be quite acceptable and relatively low. For hardened_malloc in particular, it won't make a significant difference. It already pays most of the required costs and will actually get to disable some features like canaries.
1
Replying to and
Memory tagging is particularly suited to slab allocators with slabs dedicated to specific size classes as can be seen from my section on it. It will work even better for hardened_malloc due to having regions dedicated to size classes without reuse of address space between them.
1
Replying to and
The generation-based approach to tagging for deterministic use-after-free mitigation combined with size class regions and the quarantine will work extremely well together to provide very powerful deterministic use-after-free defences, along with secondary probabilistic defences.
1
Show replies