similar to: [PATCH nbdkit v2 0/2] Implement fuzzing using Clang's libFuzzer.

libFuzzer is Clang's fuzzer, and alternative to using AFL: https://llvm.org/docs/LibFuzzer.html I implemented an alternative method of fuzzing for libnbd earlier today and it's pretty simple: https://github.com/libguestfs/libnbd/commit/c19a6fbae9a21a7d4693418706c59e81ed256875 However it's considerably more difficult to use libFuzzer with non-library code -- in this case nbdkit.

VDDK plugin + --run was broken because of the following sequence of events: (1) After .config_complete, server redirects stdin/stdout to /dev/null. (2) Server then calls vddk_get_ready which reexecs. (3) We restart the server from the top, but with stdin/stdout redirected to /dev/null. So saved_stdin/saved_stdout save /dev/null. (4) run_command is called which "restores"

I am working of using libfuzzer and asan to test out a third-party library. As demonstrated in the tutorial, I wrote a fuzz target to fuzz a specific function in the library. The fuzz target is then linked to the library and compiles clean and I do see some tests generated by the fuzzer. However, I have some questions regarding the "right" way to go about doing this. I have doubts that

Hi Mitch, Thank you for the response. 1. You don't need to build the library with `-fsanitize-coverage=...`, using `-fsanitize=fuzzer-no-link,address` should be sufficient. - Acknowledged 2. (although you can actually build object files/shared libraries with -fsanitize=fuzzer, and the libFuzzer main won't be linked, if this makes your build process easier). - with just the *fuzzer

Eric: Did you want to take this one any further? It might be one that we save for > 1.18: https://www.redhat.com/archives/libguestfs/2020-February/thread.html#00206 Another thing I've been thinking about for some time is splitting .config_complete into .config_complete + .get_ready (new name TBD). At the moment .config_complete is both the place where we finish processing config, and

> I really like the property of libFuzzer living in its own place so that > it's easy to use without building the world But it’s not: the implementation of the coverage instrumentation is done in one of the sanitizers, so it’s impossible to just use libFuzzer without them. Furthermore, I would think that almost all libFuzzer users would use a sanitizer while fuzzing. I can see a few

On Sun, Aug 30, 2015 at 9:11 AM, Brian Cain via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On Sun, Aug 30, 2015 at 9:30 AM, Greg Stark via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> I have a project I want to do based on Libfuzzer. Is there a separate >> list for it or should I bring up any ideas for it here? >> >> No separate

Hello, Is this reproducible? > Fuzzing is a probabilistic business and one or even two runs don't prove > much. > I've reproduced the behavior on two different machines. Attached is a script to do so. To use the script, - create an empty folder and copy both prune-blocks.sh and ff-http-parser.sh in there - ensure clang and clang++ are in your $PATH - cd /path/to/prune-blocks.sh

I have a project I want to do based on Libfuzzer. Is there a separate list for it or should I bring up any ideas for it here? What I have in mind is to fuzz Postgres. Trying to fuzz the SQL interpreter in general is not very productive because traditional fuzzers try to execute the entire program repeatedly and it has a fairly high startup and shutdown cost. Also the instrumentation-guided

Hi everyone, I wrote a prototype based on LLVM sanitizer infrastructure to improve fuzzing performance, especially over sparse file format. I’d like to upstream it if the anyone thinks it is useful. Sparse file format are formats that only a small portion of the file data could have impact on the behavior of the program that parses it. Common examples are archive files or a file system image

For commands with long names and/or short descriptors, you can end up going over 72 characters in the first line of the man page (causing podwrapper to complain). Wrap these lines. --- generator/generator | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/generator/generator b/generator/generator index 7d3f656..ad1cb6b 100755 --- a/generator/generator +++ b/generator/generator

HI think I have a fairly nicely integrated Libfuzzer based fuzzer in Postgres now. I can run things like: SELECT fuzz(100000,'select regexp_matches(''foo/bar/baz'',$1,''g'')') Which makes it convenient to fuzz arbitrary public functions available in SQL. (I haven't figured out what interface to make for fuzzing internal functions which take char

Hi, As a part of a recent move of libFuzzer from LLVM to compiler-rt I am looking into updating the build code for the libraries which use libFuzzer. I have tried to compile llvm-mc-assemble-fuzzer, and llvm-mc-disassemble-fuzzer, and I couldn’t build either of those. For the first one, the reason is that it refers to a nonexistent enum, and for the second one I believe the reason is that it

Greg, This is lots of useful feedback! I'll reply to individual bullets when time permits (mostly after the holidays). If you find a bug in Postgres with libFuzzer, please let us know so that we can add it to http://llvm.org/docs/LibFuzzer.html#trophies On Sat, Sep 5, 2015 at 8:40 AM, Greg Stark via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Sat, Sep 5, 2015 at 1:50 PM,

Hi all, While playing with libFuzzer, it's a little cumbersome to having to copy the buffer just in order to null-terminate it. Is a null-terminated buffer an often-enough usage scenario to warrant a libFuzzer commandline configuration switch to always generate a null-terminated test case? Thanks, Johan -------------- next part -------------- An HTML attachment was scrubbed... URL:

> On Sep 21, 2016, at 9:36 AM, Kostya Serebryany via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Exciting! > > (btw, I'd prefer libfuzzer at googlegroups.com <mailto:libfuzzer at googlegroups.com> for such discussions, please start new topics there) You mean a LLVM library has a separate mailing-list? Why? — Mehdi > > I can reproduce this too, but

I think libfuzzer deserves its own flag. I view fuzzing as a smarter testing technology while sanitizers are associated with inserting additional checks into the program. The different linking behavior is another major difference. Anna. > On Apr 27, 2017, at 4:08 PM, Kostya Serebryany via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > on the one hand, -fsanitize=fuzzer might

Hi All, Recently we have introduced a short syntactic sugar flag for compiling a file with libfuzzer: one just needs to add “-fsanitize=fuzzer” to the command line, and the driver would specify coverage flags and link with libfuzzer automatically. I wanted to ask whether it would make more sense to rename the flag to “-ffuzzer”, as it’s not a sanitizer, and it has a much heavier effect. Thanks,

The patches following do indeed allow you to compile nbdkit.exe, but it does not actually work yet. I'm posting this experimental series more as a work in progress and to get feedback. Note this does not require Windows itself to build or test. You can cross-compile it using mingw64-* packages on Fedora or Debian, and test it [spoiler alert: it fails] using Wine. Rich.

r247321 refactors the code so that it should build on Mac. I haven't actually tested it on Mac -- so please help me and send follow up patches if needed. check-fuzzer will still fail because some of the libFuzzer tests require dfsan. I'd use some help from someone with a Mac to modify lib/Fuzzer/test/CMakeLists.txt so that it does not run dfsan-dependent tests on Mac. Thanks, --kcc On