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.


>
> > 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.

Reply via email to