On Wed, Feb 17, 2016 at 10:52 PM, Konstantin Serebryany <[email protected]> wrote: > > > On Wed, Feb 17, 2016 at 11:50 AM, Yuri Gribov <[email protected]> wrote: >> >> On Wed, Feb 17, 2016 at 5:45 PM, Konstantin Serebryany >> <[email protected]> wrote: >> > +Roland >> > >> > The only good solution is to have the upstream glibc fixed and >> > maintained in >> > this state. >> > (We need to make it build with clang+asan and have the bots that verify >> > it >> > still works on every commit). >> >> Why not sanitize it with GCC though? > > > You can, it's not much simpler. I've tried. > You will avoid the clang-specific problems, but you still can not build the > entire thing with asan. > But if you want to fuzz glibc, you'll need the coverage instrumentation. > GCC has the one that we use in the kernel, but not the one we use with > libFuzzer.
I guess it would be much easier to port coverage to GCC than to build Glibc and convince maintainers to take Clang-specific patches ;) >> > Roland wanted to try doing that; not sure what's the current state. >> > Anyway, I think this should be discussed at [email protected] >> > >> > >> > On Wed, Feb 17, 2016 at 3:21 AM, Hanno Böck <[email protected]> wrote: >> >> >> >> Hi, >> >> >> >> I thought given the current issues with glibc I'd bring that up. >> >> >> >> A while ago I had a conversation with Kostya about building glibc with >> >> asan. I think it can be summed up as "it's possible, but requires lots >> >> of manual work and is complicated". >> >> >> >> The publicly available documentation is currently a wiki page listing >> >> problems trying to build glibc with clang >> >> https://sourceware.org/glibc/wiki/GlibcMeetsClang >> >> and some reports about fuzzing done with libfuzzer >> >> https://sourceware.org/glibc/wiki/FuzzingLibc >> >> >> >> As far as I can see there is currently no public documentation how one >> >> would compile glibc with asan (and/or libfuzzer). >> > >> > >> > True. My current instructions are pretty involved. >> > Let me dump them here FTR (last checked 1 month ago). >> > >> > First, build glibc in a usual way: >> > >> > wget http://ftp.gnu.org/gnu/glibc/glibc-2.22.tar.bz2 >> > tar xf glibc-2.22.tar.bz2 >> > ( >> > mkdir glibc_build_plain >> > cd glibc_build_plain/ >> > ../glibc-2.22/configure --prefix=`pwd`/../glibc_inst_plain && make -j && >> > make install >> > ) >> > >> > Grab fresh clang. >> > Revert clang r255371, or apply this patch. Then rebuild clang. >> > (This is a long and sad story... Hopefully Roland will fix it) >> > >> > --- llvm/tools/clang/lib/Sema/SemaDecl.cpp (revision 257672) >> > +++ llvm/tools/clang/lib/Sema/SemaDecl.cpp (working copy) >> > @@ -2381,7 +2381,7 @@ >> > // Attributes declared post-definition are currently ignored. >> > checkNewAttributesAfterDef(*this, New, Old); >> > >> > - if (AsmLabelAttr *NewA = New->getAttr<AsmLabelAttr>()) { >> > + if (0) if (AsmLabelAttr *NewA = New->getAttr<AsmLabelAttr>()) { >> > if (AsmLabelAttr *OldA = Old->getAttr<AsmLabelAttr>()) { >> > if (OldA->getLabel() != NewA->getLabel()) { >> > // This redeclaration changes __asm__ label. >> > >> > >> > Now, download the attached clang-gcc-wrapper.py and put it into ./ >> > >> > Build using clang-gcc-wrapper.py instead of gcc: >> > ( >> > mkdir glibc_build_clang # name is important for clang-gcc-wrapper.py >> > cd glibc_build_clang >> > CC=`pwd`/../clang-gcc-wrapper.py ../glibc-2.22/configure >> > --prefix=`pwd`/../glibc_inst_clang >> > make -k # -j >> > ) >> > >> > The build will fail to complete (thus -k), but it will produce all >> > needed >> > .so >> > files. >> > Now, copy .so files to glibc_build_plain/: >> > >> > for f in librt libdl libresolv libpthread libcrypt libm; do cp -v >> > glibc_build_clang/*/$f.so glibc_inst_plain/lib/$f-2.22.so; done >> > cp glibc_build_clang/libc.so glibc_inst_plain/lib/libc-2.22.so >> > >> > Note: if you are building version other than 22, change the names. >> > >> > >> > Now, verify that you have proper instrumentation. >> > >> > % cat use-after-free-on-gethostbyname.c >> > #include <netdb.h> >> > #include <stdlib.h> >> > int main() { >> > char *x = (char*)malloc(10); >> > free(x); >> > gethostbyname(x); >> > } >> > >> > % export SYSROOT=`pwd`/glibc_inst_plain/ >> > % clang -g -fsanitize=address use-after-free-on-gethostbyname.c \ >> > -Wl,-rpath=$SYSROOT/lib -Wl,-dynamic-linker=$SYSROOT/lib/ld-2.22.so >> > % ASAN_OPTIONS=replace_str=0 ./a.out >> > >> > You should get >> > >> > ==25426==ERROR: AddressSanitizer: heap-use-after-free on address >> > 0x60200000eff0 >> > at pc 0x7f65db399e2d bp 0x7ffe902a0c50 sp 0x7ffe902a0c48 >> > READ of size 1 at 0x60200000eff0 thread T0 >> > #0 0x7f65db399e2c in __GI___libc_res_nsearch >> > glibc-2.22/resolv/res_query.c:356:18 >> > >> > >> > NOTE: you should get the first frame inside the glibc code, not inside >> > asan >> > interceptor. Compare to running w/o ASAN_OPTIONS=replace_str=0: >> > >> > #0 0x49a490 in index >> > llvm/projects/compiler-rt/lib/asan/asan_interceptors.cc:470:5 >> > >> > Finally, have a look at clang-gcc-wrapper.py to make sure you instrument >> > all >> > the >> > code you need: >> > >> > asan_whitelist = [#"posix", >> > "string", "wcsmbs", "wctype", "stdio-common", "time", >> > "resolv"] >> > >> > Some parts of glibc still don't build with clang, so we are using a >> > whitelist. >> > >> > >> > --kcc >> > >> >> >> >> >> >> I think it is a major drawback of security analysis of glibc that many >> >> common tools don't work on it and it'd be great if this area could be >> >> improved. So the question is: How realistic would it be to make this >> >> stuff more easily accessible? >> >> >> >> -- >> >> Hanno Böck >> >> https://hboeck.de/ >> >> >> >> mail/jabber: [email protected] >> >> GPG: BBB51E42 >> >> >> >> -- >> >> You received this message because you are subscribed to the Google >> >> Groups >> >> "address-sanitizer" group. >> >> To unsubscribe from this group and stop receiving emails from it, send >> >> an >> >> email to [email protected]. >> >> For more options, visit https://groups.google.com/d/optout. >> > >> > >> > -- >> > You received this message because you are subscribed to the Google >> > Groups >> > "address-sanitizer" group. >> > To unsubscribe from this group and stop receiving emails from it, send >> > an >> > email to [email protected]. >> > For more options, visit https://groups.google.com/d/optout. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "address-sanitizer" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/d/optout. > > > -- > You received this message because you are subscribed to the Google Groups > "address-sanitizer" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "address-sanitizer" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
