Conversation

Some initial documentation for my new hardened malloc implementation: github.com/AndroidHardeni It's still in an early state of development with major parts of the core design and many security features not yet implemented. It should work with nearly any programs already though.

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

You’re unable to view this Tweet because this account owner limits who can view their Tweets. Learn more

Replying to

and

Scudo is entirely based on inline metadata and free lists. It relies on CRC32 to detect metadata corruption and can't reliably detect invalid free in the same way. Having fully out-of-line metadata is extremely important for providing many other security properties too.

Replying to

and

Similarly, it can't offer the same kind of fine-grained randomization. One of the biggest differences is that the design I'm using is isolating each size class with a unique random base within the outer reserved region rather than a dlmalloc-style allocator mixing it together.

Replying to

and

Metadata is entirely out-of-line with no deterministic offsets to it and similarly there are no deterministic offsets between size classes. Address space is reserved for a size class and never reused for another. It's a bit like PartitionAlloc, but with much stronger isolation.

Replying to

and

Here's a simple demonstration of the size class isolation with high entropy bases per size class region: gist.github.com/thestinger/dd7 It shows the output with glibc as a baseline, where other than the system sbrk and mmap base it's predictable and mixed together in shared regions.

gist.github.com

offset.c

GitHub Gist: instantly share code, notes, and snippets.

Replying to

and

My goal is providing better security properties than OpenBSD malloc, which also uses a hardened design from the bottom up with fully out-of-line metadata. It's also going to have much better performance, lower memory overhead and far better scalability than OpenBSD malloc.

10:43 PM · Aug 27, 2018Twitter Web Client

Replying to

and

OpenBSD malloc performance is good enough for the real world and it's possible to do much better without sacrificing security. I'd consider the core of any hardened allocator to be authoritative out-of-line metadata and it makes performance a challenge, but it can still be done.

Replying to

and

Similarly, thread caches (or queues) are at odds with having an authoritative source for everything able to perform good double-free and invalid free detection. It's possible to offer great scalability without them with arenas, especially layered on top of fine-grained locking.

Show replies