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

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.

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

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

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.

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

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.

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

1

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.

1

Replying to

and

The various forms of fine-grained randomization like the randomized quarantine array and slot randomization work together with tagging to make this more difficult too. Also need to keep in mind that the tags are still initially randomized. It also synergizes incredibly well.

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