I don’t know Zig, like, at all, but I think this page is probably pretty misleading. For instance: it says Zig is susceptible to UAF. But Zig wires its allocator not to reuse address space; if you touch freed memory, you’ll SEGV.
Conversation
Replying to
yes, but isn't performance going to be really bad if you never reuse freed memory. you're at the very least going to have a bunch more syscalls?
2
4
Consider a loop that calls malloc(16) and free(16) repeatedly. Normally the allocations will always be in cache. But in an allocator that never reuses memory every new page will miss.
1
3
Indeed this example will be slow, but who calls malloc/free in a hot loop?
There's also a much more granular safety story - you could allow some of your trusted dependencies to be compiled in ReleaseFast mode but most of your application in ReleaseSafe.
4
3
We've had a long time to determine the answer to the question of whether it matters in practice that the memory malloc returns is in cache, and the answer is that yes, it does.
3
5
The state-of-the-art in hardened malloc is 's github.com/GrapheneOS/har and it does quarantine for large objects only (I think, could be wrong).
1
7
It has optional quarantines for both small and large allocations as separate features. Large means a mmap region with guards.
In both cases, it has a random quarantine based on swapping with a random element in an array and a ring buffer as a queue for a deterministic delay.
For the large allocation quarantine, it replaces the allocation with fresh PROT_NONE pages so it's essentially a virtual memory quarantine.
Either way, it always deterministically detects any invalid free of any pointer that's not a valid non-free, non-quarantined allocation.
1
2
By default, the configuration is very security centric with all security features enabled other than the somewhat superfluous MPK-based metadata protection.
Quarantines are largely separate from the core code other than slab metadata having an extra bitmap for quarantined slots.
2
1
Show replies