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.
2
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
Replying to
Yeah. I'm not a big fan of how Linux treats the stack. Their stack clash mitigation had several issues. FreeBSD's stack implementation is pretty nice, comparatively. :)
1
Replying to
The way it does secondary stacks is perfectly fine. I think the current main thread stack implementation is finally robust. It took many years for it to evolve into something without substantial issues though. I think needing to use MAP_GUARD everywhere probably isn't ideal.
Ideally, the main thread stack would be a fixed size with the executable needing to configure the size in the executable (still limited by the resource limit) if they need more than the default. The legacy stack growth mechanism should really just be removed in the long term.
1
1
Replying to
Agreed. There are a couple issues with the MAP_GUARD impl in fbsd. I've noticed crashes when configuring it to use more than one 4KB page for the stack guard.
I gotta study up on it a bit more to figure out the root cause and come up with an upstreamable fix.
1
Show replies
Replying to
Well, "needing" to use MAP_GUARD and "wanting" to use it are two different things. ;)