From: "Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>
To: Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
Andrew Cooper <andrew.cooper3@citrix.com>,
Jan Beulich <jbeulich@suse.com>, Julien Grall <julien@xen.org>,
Bertrand Marquis <bertrand.marquis@arm.com>,
Michal Orzel <michal.orzel@amd.com>,
Dario Faggioli <dfaggioli@suse.com>,
Juergen Gross <jgross@suse.com>,
George Dunlap <gwd@xenproject.org>
Subject: Re: [RFC PATCH] xen: add libafl-qemu fuzzer support
Date: Wed, 20 Nov 2024 02:20:50 +0100 [thread overview]
Message-ID: <Zz05dJdAOvaKKrag@mail-itl> (raw)
In-Reply-To: <875xojmexk.fsf@epam.com>
[-- Attachment #1: Type: text/plain, Size: 1005 bytes --]
On Tue, Nov 19, 2024 at 03:16:56PM +0000, Volodymyr Babchuk wrote:
> > Honestly, aside from these two comments, this looks quite good. I would
> > suggest adding a GitLab CI job to exercise this, if nothing else, to
> > serve as an integration point since multiple components are required for
> > this to work.
>
> I was considering this as well. Problem is that fuzzing should be
> running for a prolonged periods of time. There is no clear consensus on
> "how long", but most widely accepted time period is 24 hours. So looks
> like it should be something like "nightly build" task. Fuzzer code
> needs to be extended to support some runtime restriction, because right
> now it runs indefinitely, until user stops it.
Regardless of the actual fuzzing (which takes time), I'd suggest to add
a gitlab job that does sanity test, checks if stuff still builds etc. It
can probably be limited to 1min fuzzing or such.
--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2024-11-20 1:21 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-14 22:46 [RFC PATCH] xen: add libafl-qemu fuzzer support Volodymyr Babchuk
2024-11-19 1:46 ` Stefano Stabellini
2024-11-19 15:16 ` Volodymyr Babchuk
2024-11-19 18:32 ` Andrew Cooper
2024-11-19 20:46 ` Volodymyr Babchuk
2024-11-19 23:23 ` Stefano Stabellini
2024-11-20 0:50 ` Volodymyr Babchuk
2024-11-20 22:07 ` Stefano Stabellini
2024-11-21 23:15 ` Volodymyr Babchuk
2024-11-22 0:37 ` Stefano Stabellini
2024-11-25 23:23 ` Volodymyr Babchuk
2024-11-20 1:20 ` Marek Marczykowski-Górecki [this message]
2024-11-20 22:05 ` Stefano Stabellini
2024-11-19 18:02 ` Andrew Cooper
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=Zz05dJdAOvaKKrag@mail-itl \
--to=marmarek@invisiblethingslab.com \
--cc=Volodymyr_Babchuk@epam.com \
--cc=andrew.cooper3@citrix.com \
--cc=bertrand.marquis@arm.com \
--cc=dfaggioli@suse.com \
--cc=gwd@xenproject.org \
--cc=jbeulich@suse.com \
--cc=jgross@suse.com \
--cc=julien@xen.org \
--cc=michal.orzel@amd.com \
--cc=sstabellini@kernel.org \
--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.