llvm dev - Aug 2017 - libFuzzer: add an option to always null-terminate?

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:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170802/1c9a17e6/attachment.html>

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)

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

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.

--kcc

>
> Thanks,
>   Johan
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170802/1e117306/attachment.html>

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>