This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: alloca vs malloc
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: OndÅej BÃlka <neleai at seznam dot cz>
- Cc: Jeff Law <law at redhat dot com>, Rich Felker <dalias at libc dot org>, Florian Weimer <fweimer at redhat dot com>, Will Newton <will dot newton at linaro dot org>, Konstantin Serebryany <konstantin dot s dot serebryany at gmail dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Sat, 17 May 2014 00:07:54 +0000
- Subject: Re: alloca vs malloc
- Authentication-results: sourceware.org; auth=none
- References: <CAGQ9bdw135gBO+cTQx3Ws1GrRgFsi8-j=Y_mZ=ixebpPzB4gXw at mail dot gmail dot com> <53760025 dot 10204 at redhat dot com> <CANu=DmhF=PZBVHtOPw5ZMCHjcy6vqdCvrRvY+xO9hzfkjTCRQA at mail dot gmail dot com> <53760826 dot 6090203 at redhat dot com> <20140516135304 dot GA29829 at domone dot podge> <20140516190504 dot GF507 at brightrain dot aerifal dot cx> <20140516203140 dot GA16889 at domone dot podge> <53768528 dot 1020502 at redhat dot com> <20140516232039 dot GA18631 at domone dot podge>
On Sat, 17 May 2014, Ondrej Bilka wrote:
> For libc there are better alternatives, I will add priority to malloca
> cleanup. As glibc code is now alloca are mostly
> trivial or following this pattern occuring about hundred times:
I suggest doing such cleanup in a maximally conservative and incremental
way:
* If you can identify an existing pattern that can be abstracted (with a
macro or inline function) in such a way that the code generated does not
change at all, the change is safer and easier to review than one that
causes lots of changes to code generation - even if you then end up with
several different macro / inline function abstractions for slightly
different existing patterns, and there is then a followup stage where a
preferred pattern is chosen and other variants converted over to it.
* If checks are inserted where missing then:
- Deal with separate cases separately rather than having a big patch
with lots of separate changes each of which needs individual review.
- For each such case of a missing check, file a bug in Bugzilla and try
to give some indication of the circumstances in which overflow might
occur. (Sometimes there may be reasons like "this can't actually
overflow on Linux because Linux limits the total size of the
environment" or similar - given that glibc supports more than Linux
and it shouldn't necessarily be presumed such limits will stay in
Linux in future, such cases should still be fixed in line with the GNU
principle of avoiding arbitrary limits.) I expect distribution
security people will then want to look at these bugs in more detail to
decide if there should be a CVE.
- New checks should follow the patterns with the widest existing
practice in glibc rather than e.g. using __int128 or saturating
arithmetic. It's quite possible some other form is in fact more
efficient, but using the existing style is more conservative - once
all such checks are using just a few macros / inline functions, any
change to the style of the checks can be considered as a separate
matter from adding the checks.
* Likewise in cases where checks are present but incorrect.
Yes, this inevitably means a large number of small patches (and lots of
bugs in Bugzilla for fairly obscure issues) - I think it's best if the
only big patches in this area are ones that don't change the code
generated for installed shared libraries at all.
--
Joseph S. Myers
joseph@codesourcery.com