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 13:44:22 +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>
On 05/29/2013 09:29 AM, Will Newton wrote:
Are there specific design goals of the current code? For example, if a
new implementation increased memory usage but increased performance
would that be acceptable?
That obviously depends on the increases. 8-)
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.
For compatibility with legacy applications, an allocator which has (at
least optionally) limited deterministic behavior in the face of
use-after-free and double-free bugs in applications might gain
acceptance more easily. This is an ugly workaround for sure, but would
simplify initial porting of some code bases.
--
Florian Weimer / Red Hat Product Security Team