A very serious problem with never reusing malloc addresses that I realized: fragmentation. Even 1 allocated byte in your 4kB page will keep the whole page alive. This can result in enormous wasted space.
Conversation
Replying to
That's the contrast I was making here:
twitter.com/DanielMicay/st
For large allocations, the memory is directed replaced with fresh PROT_NONE pages. For small (slab) allocations, they have to be quarantined case-by-case and those are spread out across many slabs. It costs a lot.
Quote Tweet
Replying to @pcwalton @andy_kelley and @saleemrash1d
It wouldn't work for small allocations as currently implemented. It doesn't currently pay the cost of aggressively purging memory held onto by the slab allocation quarantine. That's something we're working on improving. For large allocations... you'll run out of address space.
1
1
It's also a lot more expensive to manage the allocations as distinct mapped regions.
That's part of why hardened_malloc has the option (CONFIG_EXTENDED_SIZE_CLASSES) to use slab allocation even once the size classes are multiples of the page size:
It's possible to configure it to switch over for > 16k and to use a massive large allocation quarantine. That has a substantial cost. It's way harder for the smaller allocations. Part of how we handle it is not ever reusing address space for metadata or different size classes.
1
twitter.com/DanielMicay/st
ARMv8.4 memory tagging will be able to multiply the amount of time that an allocation is protected by an amount like 32x by incrementing the previous tag (cyclically) for each allocation. So, it has to go through the quarantine 32x before it wraps around.
Quote Tweet
Replying to @DanielMicay @andy_kelley and @pcwalton
So, for example, choose a random tag for an allocation. On free, set it to the reserved tag. On allocation, increment the previous random tag and set it to that.
Can get deterministic detection of use-after-free until it wraps all the way back around and reuses a previous tag.
1
Show replies