[llvm-dev] libFuzzer: add an option to always null-terminate?

[Johan Engelen via llvm-dev]

On Wed, Aug 2, 2017 at 9:42 PM, Kostya Serebryany <kcc at google.com> wrote:

>
>
> On Wed, Aug 2, 2017 at 12:24 PM, Johan Engelen via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Hi all,
>>   While playing with libFuzzer, it's a little cumbersome to having to
>> copy the buffer just in order to null-terminate it.
>>
>
> It's just one line, isn't it?
> (Well, in C++; in C this would be 3 lines)
>

One? I know how to in two. Teach me :)  (unfortunately in D, it's 4 lines)


>
>> Is a null-terminated buffer an often-enough
>>
>
> It's somewhat frequent, yes.
>
>
>> usage scenario to warrant a libFuzzer commandline configuration switch to
>> always generate a null-terminated test case?
>>
>
> Such option will need to be *off* by default,
>

definitely


> because there are lots of cases where we must not null-terminate the input
> (otherwise we'll hide some bugs).
> And when an option is off by default and some targets *require* it to be
> on in order to function properly it becomes a very bad idea, IMHO.
>

That's a good argument. I had not realized that all of the other options
aren't requirements (although I've been abusing -only_ascii for that a
little bit). Adding `if (data[size-1]) return 0;` to remove the requirement
probably doesn't work well with the mutation algorithm.
I was hoping I could elide the buffer allocation and copy.


> Besides, the LLVMFuzzerTestOneInput is supposed to be a general interface
> between the APIs under test and any fuzzing engine (AFL, honggfuzz, SAGE,
> KLEE, etc) and we should not expect all of them to implement the flag.


I was quite surprised not being able to find an option to null terminate :)

-Johan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170802/3a314048/attachment.html>