This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Enhancing malloc
- From: Florian Weimer <fweimer at redhat dot com>
- To: Will Newton <will dot newton at linaro dot org>
- Cc: "Carlos O'Donell" <carlos at redhat dot com>, Siddhesh Poyarekar <siddhesh at redhat dot com>, OndÅej BÃlka <neleai at seznam dot cz>, libc-alpha <libc-alpha at sourceware dot org>
- Date: Wed, 29 May 2013 15:02:25 +0200
- Subject: Re: Enhancing malloc
- References: <CANu=Dmj34hZoWr8A5dPThv14XUmP8vTgsxFLAbJ9jTTabRPqqA at mail dot gmail dot com> <20130528123317 dot GA17360 at domone dot kolej dot mff dot cuni dot cz> <20130528125444 dot GC2145 at spoyarek dot pnq dot redhat dot com> <51A50991 dot 7010100 at redhat dot com> <CANu=DmgciQkeWfS8TBq2FVokBQXQCG2V6tmYU+9jhmfCF_9GcQ at mail dot gmail dot com> <51A5EA16 dot 3070707 at redhat dot com> <CANu=Dmg-f9O_UOCw0Zk3ZDu_PK4hGcVq0W6VFET4_O26_jxjaA at mail dot gmail dot com>
On 05/29/2013 02:53 PM, Will Newton wrote:
Other things to consider are fork friendliness and the impact of buffer
overruns and double-free bugs in application programs in terms of actual
security vulnerabilities.
What do you mean by "fork friendliness" in this context?
The metadata updates performed by malloc/free can trigger copying of
pages shared between the parent and child processes. An obvious
candidate for such behavior is a hash table keyed by the pointer
returned by malloc. Under this criterion, schemes which do not colocate
metadata with object data tend to fare less well than schemes which do.
--
Florian Weimer / Red Hat Product Security Team