Date: Mon, 11 May 2020 13:51:39 -0400 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: Re: mallocng progress and growth chart On Sun, May 10, 2020 at 02:09:34PM -0400, Rich Felker wrote: > I just pushed a big queued set of changes to mallocng, including some > directions that didn't go well and were mostly reversed but with > improvements to the old. These include: > > - Fixes to definitions of some size classes where counts didn't fit in > a power-of-two sized mmap or containing-group. > > - Fixing bad interaction between realloc and coarse size classing > (always causing malloc-memcpy-free due to size class not matching; > this was what was making apk and some other things painfully slow). > > - Coarse size classing down to class 4 (except 6->7). This tends to > save memory in low-usage programs. > > - Improvements to logic for single-slot and low-count groups to avoid > situations that waste lots of memory as well as ones that > unnecessarily do eagar allocation. > > - Flipping definition/dependency of aligned_alloc/memalign so that > legacy nonstd function is not used in definition of std functions. > > - New bounce counter with sequence numbers and decay, so that bounces > with lots of intervening expensive (mmap/munmap) ops don't get > accounted, and classes in bouncing state (retaining a free group > unnecessarily to avoid cost of un- and re-mapping) can return to > non-bouncing state. I left off one fairly important one: - Hardening enhancement: clearing the pointer back to the group's meta struct before freeing the group, so that the next time the memory is handed out in an allocation the uninitialized memory doesn't contain pointers to malloc internal structures. For example: free(malloc(42)); p=malloc(492); would include a pointer to the freed meta structure for the nested group, at offset 0 or 16 if I'm not mistaken. This could allow uninitialized memory leak plus a second difficult-to-exploit bug to be transformed into an easier-to-exploit bug. This also suggested to me that we could clear the pointer back to meta whenever a group is entirely free slots but not itself freed, and restore it only when it's subsequently used. This might have minor hardening benefits too, but it highlights that we could use MADV_FREE on such groups, which might be valuable at large sizes. OTOH MADV_FREE has some anti-hardening properties (potentially loses offset cycling state under attacker-controlled load, allowing the attacker to obtain more predictable addresses) that make it less attractive to use here.
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.