This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Google Summer of Code projects for the GNU C Library.
- From: OndÅej BÃlka <neleai at seznam dot cz>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: Konstantin Serebryany <konstantin dot s dot serebryany at gmail dot com>, Carlos O'Donell <carlos at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Fri, 21 Feb 2014 13:53:18 +0100
- Subject: Re: Google Summer of Code projects for the GNU C Library.
- Authentication-results: sourceware.org; auth=none
- References: <530548F5 dot 7090401 at redhat dot com> <CAGQ9bdwt6orzq0ap4UH7f7ZfAEMOGuxrSq0PBVcqW3hm3nrC-w at mail dot gmail dot com> <Pine dot LNX dot 4 dot 64 dot 1402210136090 dot 7834 at digraph dot polyomino dot org dot uk>
On Fri, Feb 21, 2014 at 01:45:31AM +0000, Joseph S. Myers wrote:
> On Thu, 20 Feb 2014, Konstantin Serebryany wrote:
>
> > Idea for glibc GSoC project: instrument the glibc source with
> > AddressSanitizer (asan).
> > https://code.google.com/p/address-sanitizer/
> > goal #1: test glibc itself for bugs like stack or global buffer overflow.
>
> I suspect most interesting such bugs are for cases involving extreme (but
> valid) input that's currently not covered by the testsuite. In my
> experience it's quite easy to find problems with memory allocation just by
> looking for them; it might be interesting to have a project to review
> allocations in glibc more thoroughly, especially where the size depends on
> user input.
>
I already done review, most of these could be solved by not duplicating
same allocation pattern in 100 of places. Using malloca and saturated
arithmetic will dramaticaly cut number of possible errors.