Matthias Maennich via elfutils-devel
Mon Jan 6 13:17:00 GMT 2020
On Thu, Dec 26, 2019 at 11:50:48PM +0100, Mark Wielaard wrote:
>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:
>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:
>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.
>> On Mon, Dec 23, 2019 at 3:12 AM Mark Wielaard <firstname.lastname@example.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
More information about the Elfutils-devel