|
Message-ID: <CAHD6eXfpMWc54_ce6gf4pbK4MUdp2G=ZPkDZh4GoM3AbrzGmbQ@mail.gmail.com> 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.