I added a section to the hardened malloc documentation on the chosen approach to memory tagging for slab allocations:
github.com/AndroidHardeni
In addition to guaranteed linear overflow detection, it will guarantee that use-after-free is detected until the tag wraps all the way.
Conversation
Despite only having 4 bit tags, it's guaranteed to take fairly long to wrap around due to the FIFO quarantine providing a guaranteed delay on reuse of the slot each time. The randomized portion of the quarantine and randomized slot / slab selection will give it even more value.
1
1
The initial tag values will be randomly chosen via the same efficient ChaCha8 CSPRNG already used for several other purposes. Randomized tags provide a baseline of weak probabilistic heap corruption detection between any allocations, but deterministic guarantees are much nicer.
1
2
It will also be possible to use memory tagging for large allocations, but those are already guaranteed to have randomly sized guard regions (at least 1 guard page) on each side and there's a virtual memory quarantine guaranteeing that address space isn't used again for a while.
1
For large allocations it would be used solely as a probabilistic mitigation for accesses between allocations and to a lesser extent probabilistic use-after-free mitigation. They already get replaced with a PROT_NONE mapping via MAP_FIXED on free and that region is quarantined.
Replying to
Slab and large allocation quarantines are similar. Both have FIFO (ring buffer) and a random array (swap with random slot). Slab allocator currently has to verify data is zero on allocation to detect write-after-free, so tagging will improve it to be more like large allocations.
1
1
It makes sense to disable the slab allocator write-after-free check when tagging is being used, which will gain back a lot of the lost performance. Similarly, canaries won't be very useful and disabling them would somewhat reduce memory usage, reducing the memory cost of tagging.
1
Replying to
1
1
Replying to
On Linux, MAP_STACK is a no-op and secondary stack mappings are just a contiguous, static mapping like other mmap mappings so it doesn't really matter. The main thread stack is a special case and has a properly enforced gap that's not a PROT_NONE region so it can't grow into one.
2
Show replies