You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is there any legitimate concern for DoS under conditions with few available free slabs and a min quarantine time? With high churn, it seems like there's a window for recently freed slabs to be in the queue, but still unavailable for allocation. Using allocation requests as units of measurement (counter vs clock) might be of use there, especially if the calling threads are tracked for race reduction and entropy purposes.
The delay is measured in terms of deallocation cycles (for the future slab allocation quarantine), or in this case number of free slabs.
There's the concept of a partial slab (partially filled) which are filled before falling back to empty slabs (very limited cache size - 64k at the moment) and then free slabs which have been purged and memory protected and need to be unprotected to use them.
Keeping more free slabs is very cheap since the only cost is the slab metadata (56 bytes, but it could be reduced to 32 bytes) and potentially an extra 2 VMAs (but not necessarily).
Slab metadata (which is out-of-line, like all metadata) has prev / next pointers for the partial / empty / free slab lists, so no ring buffer is needed. It already had a queue simply for the baseline implementation without a real quarantine. I added a randomized array, so it just needs an enforced minimum size on the queue to have a comparable quarantine:
There will also be a quarantine for slab allocations themselves, but that's more complicated since it needs to have a way of preserving double-free detection unlike large allocations where that's all provided by the page -> region_info hash table regardless. It could also potentially avoid delaying the slabs becoming free slabs if it's implemented cleverly.
Activity
sempervictus commentedon Oct 14, 2018
Is there any legitimate concern for DoS under conditions with few available free slabs and a min quarantine time? With high churn, it seems like there's a window for recently freed slabs to be in the queue, but still unavailable for allocation. Using allocation requests as units of measurement (counter vs clock) might be of use there, especially if the calling threads are tracked for race reduction and entropy purposes.
thestinger commentedon Oct 14, 2018
The delay is measured in terms of deallocation cycles (for the future slab allocation quarantine), or in this case number of free slabs.
There's the concept of a partial slab (partially filled) which are filled before falling back to empty slabs (very limited cache size - 64k at the moment) and then free slabs which have been purged and memory protected and need to be unprotected to use them.
Keeping more free slabs is very cheap since the only cost is the slab metadata (56 bytes, but it could be reduced to 32 bytes) and potentially an extra 2 VMAs (but not necessarily).
thestinger commentedon Oct 14, 2018
This is the existing quarantine for large allocations, which are memory mappings with randomly sized guard regions: https://github.com/AndroidHardening/hardened_malloc/blob/3db3e167ede6a9bd035f9145b5cb817954e150dd/malloc.c#L551-L584. It uses a randomized array and a ring buffer as a queue.
Slab metadata (which is out-of-line, like all metadata) has
prev/nextpointers for the partial / empty / free slab lists, so no ring buffer is needed. It already had a queue simply for the baseline implementation without a real quarantine. I added a randomized array, so it just needs an enforced minimum size on the queue to have a comparable quarantine:https://github.com/AndroidHardening/hardened_malloc/blob/3db3e167ede6a9bd035f9145b5cb817954e150dd/malloc.c#L424-L442
There will also be a quarantine for slab allocations themselves, but that's more complicated since it needs to have a way of preserving double-free detection unlike large allocations where that's all provided by the page -> region_info hash table regardless. It could also potentially avoid delaying the slabs becoming free slabs if it's implemented cleverly.