Welcome! Log In Create A New Profile

Advanced

Fwd: Plans for 1.9

Posted by David CARLIER 
David CARLIER
Fwd: Plans for 1.9
February 12, 2018 04:50PM
---------- Forwarded message ----------
From: David CARLIER <[email protected]>
Date: 12 February 2018 at 15:37
Subject: Plans for 1.9
To: [email protected]


Was thinking as a contrib work, making haproxy more fuzzer "compliant"
(AFL and LLVM/fuzzer for example) which would mean turning haproxy into a
shared with a separated exe but not sure it would be ever accepted :-).

Kind regards.
Willy Tarreau
Re: Fwd: Plans for 1.9
February 19, 2018 08:30AM
Hi David,

On Mon, Feb 12, 2018 at 03:38:15PM +0000, David CARLIER wrote:
> ---------- Forwarded message ----------
> From: David CARLIER <[email protected]>
> Date: 12 February 2018 at 15:37
> Subject: Plans for 1.9
> To: [email protected]
>
>
> Was thinking as a contrib work, making haproxy more fuzzer "compliant"
> (AFL and LLVM/fuzzer for example) which would mean turning haproxy into a
> shared with a separated exe but not sure it would be ever accepted :-).

To be honnest, I have absolutely no idea how it works, so I guess you'll
have to give a bit more details here. Making a shared lib out of haproxy
probably isn't a big deal. Sometimes it's just a matter of renaming main()
and linking with -shared. I don't know if that would be compatible with
what you need however.

Willy
David CARLIER
Re: Fwd: Plans for 1.9
February 19, 2018 09:00AM
Yes in the case of LLVM/fuzzer, it defines main entry point (thus if your
tests you need to define a function entry point to receive the data) hence
it is better if haproxy was a library. Now since haproxy always has been
"monolithic" I was not sure it would appeal :-)

On 19 February 2018 at 07:26, Willy Tarreau <[email protected]> wrote:

> Hi David,
>
> On Mon, Feb 12, 2018 at 03:38:15PM +0000, David CARLIER wrote:
> > ---------- Forwarded message ----------
> > From: David CARLIER <[email protected]>
> > Date: 12 February 2018 at 15:37
> > Subject: Plans for 1.9
> > To: [email protected]
> >
> >
> > Was thinking as a contrib work, making haproxy more fuzzer "compliant"
> > (AFL and LLVM/fuzzer for example) which would mean turning haproxy into a
> > shared with a separated exe but not sure it would be ever accepted :-).
>
> To be honnest, I have absolutely no idea how it works, so I guess you'll
> have to give a bit more details here. Making a shared lib out of haproxy
> probably isn't a big deal. Sometimes it's just a matter of renaming main()
> and linking with -shared. I don't know if that would be compatible with
> what you need however.
>
> Willy
>
David CARLIER
Re: Fwd: Plans for 1.9
February 21, 2018 02:20PM
Here a Work in Progress diff, here I simply build both static and shared
libraries, maybe Haproxy folks would prefer only one of those but wanted to
give the choice.
the main entry point from haproxy.c then becomes hap_main one which is the
default but in a fuzzer's perspective, it might be preferrable to just
implement what need to be tested (I just started to play with LLVM/Fuzzer
and haproxy and not sure yet if either it will belong to contrib or not
committed at all).

Let me know if I m taking a relatively correct direction for the specific
Haproxy changes.

Thanks.

On 19 February 2018 at 07:46, David CARLIER <[email protected]> wrote:

> Yes in the case of LLVM/fuzzer, it defines main entry point (thus if your
> tests you need to define a function entry point to receive the data) hence
> it is better if haproxy was a library. Now since haproxy always has been
> "monolithic" I was not sure it would appeal :-)
>
> On 19 February 2018 at 07:26, Willy Tarreau <[email protected]> wrote:
>
>> Hi David,
>>
>> On Mon, Feb 12, 2018 at 03:38:15PM +0000, David CARLIER wrote:
>> > ---------- Forwarded message ----------
>> > From: David CARLIER <[email protected]>
>> > Date: 12 February 2018 at 15:37
>> > Subject: Plans for 1.9
>> > To: [email protected]
>> >
>> >
>> > Was thinking as a contrib work, making haproxy more fuzzer "compliant"
>> > (AFL and LLVM/fuzzer for example) which would mean turning haproxy into
>> a
>> > shared with a separated exe but not sure it would be ever accepted :-).
>>
>> To be honnest, I have absolutely no idea how it works, so I guess you'll
>> have to give a bit more details here. Making a shared lib out of haproxy
>> probably isn't a big deal. Sometimes it's just a matter of renaming main()
>> and linking with -shared. I don't know if that would be compatible with
>> what you need however.
>>
>> Willy
>>
>
>
Sorry, only registered users may post in this forum.

Click here to login