mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Subject: Re: [musl] mallocng progress and growth chart
Date: Mon, 11 May 2020 13:51:39 -0400	[thread overview]
Message-ID: <20200511175138.GK21576@brightrain.aerifal.cx> (raw)
In-Reply-To: <20200510180934.GV21576@brightrain.aerifal.cx>

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.

  reply	other threads:[~2020-05-11 17:51 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-10 18:09 Rich Felker
2020-05-11 17:51 ` Rich Felker [this message]
2020-05-16  0:29 ` Rich Felker
2020-05-16  3:29   ` Rich Felker
2020-05-17  3:30     ` Rich Felker
2020-05-18 18:53       ` Rich Felker
2020-05-25 15:45         ` Pirmin Walthert
2020-05-25 17:54           ` Rich Felker
2020-05-25 18:13             ` Pirmin Walthert
2020-06-04  7:04               ` Pirmin Walthert
2020-06-04 15:11                 ` Rich Felker
2020-05-18 18:35   ` Rich Felker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200511175138.GK21576@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).