[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 25 Feb 2021 13:16:06 -0800
From: David Goldblatt <davidtgoldblatt@...il.com>
To: libc-coord@...ts.openwall.com
Subject: Re: Sized deallocation for C
On Thu, Feb 25, 2021 at 12:20 PM enh <enh@...gle.com> wrote:
> since current versions of Android use scudo rather than jemalloc, i passed this on to the scudo folks. they said that they don't see a problem with this, but make a similar point to that made by the musl maintainer --- we can't rely on untrusted input for security.
>
> so i think for Android this would provide neither performance nor security benefits, but since it can trivially be implemented as a call to free(3) i don't think it's a problem for us either.
I *think* most of the performance benefits of knowing sizes can also
be useful for hardened allocators (or at least, for certain hardened
allocator designs); the story just changes from "metadata lookups
aren't necessary" to "metadata lookups aren't on the critical path of
later operations":
- If the size is known (even though it's untrusted), you can take the
cache misses involved in the size lookup, and those involved in
redzone checking, in parallel. Otherwise, they get serialized by the
data dependency.
- The centralized allocator may still segregate objects by size-class,
and so it may be helpful to segregate them in a per-thread quarantine.
Having a good guess at the size lets the queue-append happen quickly,
for much the same reason.
I *think* in any hardened allocator, there should be at least some
hardening benefit (possibly a small one); knowing the user's opinion
lets you do strictly more checks than not knowing it does (e.g. scudo
today does size checking for C++ sized deletion, even though it
doesn't otherwise use the passed-in size).
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.
