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.

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.

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.

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

Replying to

and

So in github.com/GrapheneOS/har, you can see that the plan is to start with a random tag for the initial use and then iterate through the possible tags for future use, skipping adjacent values. The tag needs to match again for an attack based on a use-after-free vulnerability.

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

Consider this in combination with the slab allocation quarantine, which has both a FIFO ring buffer component and a randomized array. The FIFO makes it take substantially longer to get to a reused tag. It size of the ring buffer gets multiplied with the number of available tags.

Show replies