From: Jan Beulich <jbeulich@suse.com>
To: Tamas K Lengyel <tamas@tklengyel.com>
Cc: "Andrew Cooper" <andrew.cooper3@citrix.com>,
"Roger Pau Monné" <roger.pau@citrix.com>,
"Anthony PERARD" <anthony@xenproject.org>,
xen-devel@lists.xenproject.org
Subject: Re: [PATCH v3 1/2] Add libfuzzer target to fuzz/x86_instruction_emulator
Date: Mon, 22 Jul 2024 15:57:41 +0200 [thread overview]
Message-ID: <4d2d38ab-170f-4c98-9908-007adb9da950@suse.com> (raw)
In-Reply-To: <CABfawhmPm18vuqVR6S6K2Rv0nCssUsrY0jgJthVF_y7TuKVx-w@mail.gmail.com>
On 22.07.2024 15:51, Tamas K Lengyel wrote:
> On Mon, Jul 22, 2024 at 8:24 AM Jan Beulich <jbeulich@suse.com> wrote:
>>
>> On 22.07.2024 13:27, Tamas K Lengyel wrote:
>>> This target enables integration into oss-fuzz. Changing invalid input return
>>> to -1 as values other then 0/-1 are reserved by libfuzzer. Also adding the
>>> missing __wrap_vsnprintf wrapper which is required for successful oss-fuzz
>>> build.
>>>
>>> Signed-off-by: Tamas K Lengyel <tamas@tklengyel.com>
>>> ---
>>> v3: don't include libfuzzer-harness in target 'all' as it requires specific cc
>>
>> With this, how is it going to be built at all? Only by invoking the special
>> target "manually" as it seems? Which sets this up for easy bit-rotting. I
>> wonder what others think here ...
>
> Yes, by calling make with the specific target. It's not going to
> bitrot because oss-fuzz will pick up any regression on a daily basis
> to this target. I assume you would be interested in receiving the
> fuzzing reports so it would show as a build failure in case something
> broke it.
Please forgive my lack of knowledge here, but which part of whose
infrastructure would pick up stuff in a daily basis, and what fuzzing
reports (I've never seen any, daily or not) are you talking about?
For now it feels to me as if you're talking of what's possible down
the road, not what's going to happen from the moment this patch was
committed in a 2nd try. If so, the gap between both points in time
may be significant, and hence my bit-rotting concern would still
apply.
Jan
next prev parent reply other threads:[~2024-07-22 13:58 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-22 11:27 [PATCH v3 1/2] Add libfuzzer target to fuzz/x86_instruction_emulator Tamas K Lengyel
2024-07-22 11:27 ` [PATCH v3 2/2] Add tools/fuzz/oss-fuzz/build.sh Tamas K Lengyel
2024-07-22 12:20 ` Jan Beulich
2024-07-22 13:49 ` Tamas K Lengyel
2024-07-22 14:03 ` Anthony PERARD
2024-07-22 12:24 ` [PATCH v3 1/2] Add libfuzzer target to fuzz/x86_instruction_emulator Jan Beulich
2024-07-22 13:51 ` Tamas K Lengyel
2024-07-22 13:57 ` Jan Beulich [this message]
2024-07-22 14:07 ` Tamas K Lengyel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4d2d38ab-170f-4c98-9908-007adb9da950@suse.com \
--to=jbeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=anthony@xenproject.org \
--cc=roger.pau@citrix.com \
--cc=tamas@tklengyel.com \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.