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

Daniel Micay

@DanielMicay

Replying to

@lattera

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...

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

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.

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.

Show replies