Hi everyone!
On Thu, Dec 26, 2019 at 11:50:48PM +0100, Mark Wielaard wrote:
Hi Berkeley,
On Mon, Dec 23, 2019 at 08:06:54AM +0200, Berkeley Churchill wrote:
Great, thanks for the feedback!
One of my first tasks will be to support llvm/clang builds. I've seen some
prior discussion on what's needed for that, but if you have any extra tips
I'll take them. I'll be sure to create a build target for the fuzzers so
they can be run standalone.
clang is slightly inconvenient because it doesn't implement various
GNU C extensions. We even have a configure check for them now so it is
clear what we require from a C/gnu99 compiler:
https://sourceware.org/git/?p=elfutils.git;a=blob;f=configure.ac;hb=HEAD#l98
In theory when clang support that, everything should just compile.
There have been some attempts to rewrite some source code to get clang
to accept it:
https://sourceware.org/git/?p=elfutils.git&a=search&h=HEAD&st=commit&s=clang
But there is just too much code clang simply doesn't parse.
I don't know how much work there is left to get clang to accept
everything. But Matthias (CCed) said he got somewhat further on irc
once. Maybe he can share his patches.
The version of elfutils that I maintain is incomplete, but sufficient to
run libabigail on top of it and to compile everything with clang. So, my
local modifications can be summarized as:
- I use a different build system (similar to Bazel (https://bazel.build/)
- build a completely static version
- disable some warnings to build with -Werror otherwise
- Use a static config.h that is created with
./configure --without-lzma --without-bzlib and modified to
- #undef HAVE_FALLTHROUGH
- #undef HAVE_GCC_STRUCT
The source code itself is not modified for building with clang. Though I
adopted some patches from the DTS branch to build a version with builtin
ebl backends. A comparable series is merged upstream for the next
release as far as I can see.
The most tricky to address are the nested function definitions. It is
not entirely clear to me how to resolve these without completely messing
up the existing code. Most of them would end up as macro or factored out
function that takes a lot of arguments. I did not find the time to work
on a solution that is suitable upstream.
A simpler approach would be to see if oss-fuzz really needs clang at
all. As far as I know the only thing needed is a compiler supporting
inserting tracing calls into every basic block and/or comparison
operations and linking to some (C++) library that intercepts those. gcc
can do that with -fsanitize-coverage=trace-pc and/or
-fsanitize-coverage=trace-cmp (which I believe is command line
compatible with what clang uses).
I run a fuzzing project against libabigail which indirectly also fuzzes
some parts of elfutils (the subset I am compiling). So far, I did not
come across a finding in elfutils. But again, I am covering only a very
small subset of the code.
Cheers,
Matthias
Cheers,
Mark
On Mon, Dec 23, 2019 at 3:12 AM Mark Wielaard <m...@klomp.org> wrote:
> Hi Berkeley,
>
> On Fri, 2019-12-20 at 17:21 +0200, Berkeley Churchill wrote:
> > Any interest in integrating with oss-fuzz? It's a google project
> > that supports open source projects by fuzzing. It allows Google to
> > find and report bugs, especially security bugs, to the project.
> > I'm willing to work on writing fuzzers and performing the integration,
> > if this would be welcome by the maintainers. Thoughts?
>
> Certainly interested. I have been running afl-fuzz on various utilities
> and test cases. That has found lots of issues. But it isn't very
> structured. And it often needs to go through a completely valid ELF
> file before fuzzing the more interesting data structures inside it.
>
> The only request I would have is that if the fuzzer targets are added
> to elfutils itself then they should also be made to work locally. So
> someone could also use them with e.g. afl-fuzz or some other fuzzing
> framework, or simply as extra testcase.
>
> Please also see:
> https://sourceware.org/git/?p=elfutils.git;f=CONTRIBUTING;hb=HEAD
>
> Cheers,
>
> Mark
>
