Conversation

I'm curious to learn how memory safety features like memory tagging affect development techniques/practices.

Quote Tweet

Aug 21, 2019

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

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.

github.com

hardened_malloc/README.md at main · GrapheneOS/hardened_malloc

Hardened allocator designed for modern systems. It has integration into Android's Bionic libc and can be used externally with musl and glibc as a dynamic library for use on other Linux-base...

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.

3:31 PM · Aug 21, 2019Twitter Web App

Replying to

and

For protecting stack frames, the relative cost will be much higher, especially for finer-grained protection of stack variables. It will be particularly expensive for code that puts huge buffers on the stack sized based on the worst case, especially if that's hot code in a loop.

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.

Show replies