Are you folks interested in hardened allocators by chance? The OpenBSD one is fairly primitive and also terribly slow. I did some high-level design for a high-performance hardened allocator a while back and might be motivated to work on it if someone was interested in the project.
I would absolutely LOVE it if users could select which heap implementation to use at buildworld time. I’d be happy to see either OpenBSD’s malloc or GrapheneOS’s hardened_malloc (or both!) as available alternatives to the existing jemalloc in base.
In fact, I just had a small discussion on IRC about this very thing earlier today. One of my colleagues is working on benchmarking different heap implementations: https://github.com/daanx/mimalloc-bench
FYI: I’ve been carrying local patches for a couple of years to allow selecting between jemalloc and snmalloc at buildworld time. We’re doing some hardening work on snmalloc and I will probably upstream them early next year, so you should get this ability for free in a future import from FreeBSD.
That’s an excellent benchmark suite. BTW, mimalloc is a great allocator, but it’s far from “hardened”: any security-conscious allocator will avoid inline freelists entirely. The approach I settled on combines local and remote free-space bitmaps with a randomized allocation buffer to guarantee at least 8 bits of entropy for every allocation, and fully isolates all allocation metadata from user data (e.g., no metadata in slab headers, let alone in unused allocation slots). Main inspirations were mimalloc (lock-free design), scalloc (“virtual spans”), Mesh (“shuffle vectors”), and SlimGuard (randomized canaries). The key idea from recent academic research in secure allocators that existing industrial allocators don’t incorporate (AFAIK) is a guaranteed entropy lower bound for the address of every allocation. In my design, that’s 8 bits (I couldn’t see how to get it any higher while maintaining the performance characteristics I wanted). Needless to say for a secure allocator, double-frees and use-after-frees are impossible (they will either abort or segfault the program).
No, I’ve barely started the implementation. I’ll release it as soon as I have something working, but it will be a while unless I have some external impetus since I didn’t end up needing it for the day job.
Are you folks interested in hardened allocators by chance? The OpenBSD one is fairly primitive and also terribly slow. I did some high-level design for a high-performance hardened allocator a while back and might be motivated to work on it if someone was interested in the project.
I would absolutely LOVE it if users could select which heap implementation to use at buildworld time. I’d be happy to see either OpenBSD’s malloc or GrapheneOS’s hardened_malloc (or both!) as available alternatives to the existing jemalloc in base.
In fact, I just had a small discussion on IRC about this very thing earlier today. One of my colleagues is working on benchmarking different heap implementations: https://github.com/daanx/mimalloc-bench
FYI: I’ve been carrying local patches for a couple of years to allow selecting between jemalloc and snmalloc at buildworld time. We’re doing some hardening work on snmalloc and I will probably upstream them early next year, so you should get this ability for free in a future import from FreeBSD.
That’s an excellent benchmark suite. BTW, mimalloc is a great allocator, but it’s far from “hardened”: any security-conscious allocator will avoid inline freelists entirely. The approach I settled on combines local and remote free-space bitmaps with a randomized allocation buffer to guarantee at least 8 bits of entropy for every allocation, and fully isolates all allocation metadata from user data (e.g., no metadata in slab headers, let alone in unused allocation slots). Main inspirations were mimalloc (lock-free design), scalloc (“virtual spans”), Mesh (“shuffle vectors”), and SlimGuard (randomized canaries). The key idea from recent academic research in secure allocators that existing industrial allocators don’t incorporate (AFAIK) is a guaranteed entropy lower bound for the address of every allocation. In my design, that’s 8 bits (I couldn’t see how to get it any higher while maintaining the performance characteristics I wanted). Needless to say for a secure allocator, double-frees and use-after-frees are impossible (they will either abort or segfault the program).
Is you allocator’s code public?
No, I’ve barely started the implementation. I’ll release it as soon as I have something working, but it will be a while unless I have some external impetus since I didn’t end up needing it for the day job.