Re: [RFC PATCH] xen: add libafl-qemu fuzzer support

[Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>]

Hi Stefano,

(sorry, hit wrong Reply-To option, re-sending for wider audience)

Stefano Stabellini <sstabellini@kernel.org> writes:

> On Tue, 19 Nov 2024, Volodymyr Babchuk wrote:
>> Hi Stefano,
>>
>> Stefano Stabellini <sstabellini@kernel.org> writes:
>>
>> > On Thu, 14 Nov 2024, Volodymyr Babchuk wrote:
>>
>> [...]
>>
>> >> +Building LibAFL-QEMU based fuzzer
>> >> +---------------------------------
>> >> +
>> >> +Fuzzer is written in Rust, so you need Rust toolchain and `cargo` tool
>> >> +in your system. Please refer to your distro documentation on how to
>> >> +obtain them.
>> >> +
>> >> +Once Rust is ready, fetch and build the fuzzer::
>> >> +
>> >> + # git clone
>> >> https://github.com/xen-troops/xen-fuzzer-rs
>> >> +  # cd xen-fuzzer-rs
>> >> +  # cargo build
>> >
>> > Is this the only way to trigger the fuzzer? Are there other ways (e.g.
>> > other languages or scripts)? If this is the only way, do we expect it to
>> > grow much over time, or is it just a minimal shim only to invoke the
>> > fuzzer (so basically we need an x86 version of it but that's pretty much
>> > it in terms of growth)?
>>
>> Well, original AFL++ is written in C. And I planned to use it
>> initially. I wanted to make plugin for QEMU to do the basically same
>> thing that LibAFL does - use QEMU to emulate target platform, create
>> snapshot before running a test, restore it afterwards.
>>
>> But then I found LibAFL. It is a framework for creating fuzzers, it
>> implements the same algorithms as original AFL++ but it is more
>> flexible. And it already had QEMU support. Also, it seems it is quite
>> easy to reconfigure it for x86 support. I didn't tried tested this yet,
>> but looks like I need only to change one option in Cargo.toml.
>>
>> This particular fuzzer is based on LibAFL example, but I am going to
>> tailor it for Xen Project-specific needs, like CI integration you
>> mentioned below.
>
> Is my understanding correct that we only need to invoke LibAFL as you
> are doing already, and that's pretty much it? We need a better
> configuration specific for Xen, and we need one more way to invoke it to
> cover x86 but that's it? So, the expectation is that the code currently
> under
> https://github.com/xen-troops/xen-fuzzer-rs
> will not grow much?
>

Yes, it basically configures different bits of LibAFL and integrates
them together. So yes, it will not grow much. I am planning to add some
QoL things like ability to re-run specific input so it will be easier to
debug discovered issues. Or maybe tune some fuzzing algorithms
settings... But nothing big.


>
>> As for test harness, I am using Zephyr currently. My first intention was
>> to use XTF, but it is x86-only... I am still considering using XTF for
>> x86 runs.
>>
>> Zephyr was just the easiest and fastest way to trigger hypercalls. At
>> first I tried to use Linux kernel, but it was hard to cover all possible
>> failure paths. Zephyr is much simpler in this regard. Even better is to
>> use MiniOS or XTF. But ARM support in MiniOS is in sorry state and XTF
>> does not work on ARM at all.
>
> There is a not-yet-upstream XTF branch that works on ARM here:
> https://gitlab.com/xen-project/fusa/xtf/-/tree/xtf-arm?ref_type=heads

Ah, thanks. I'll try to use it as a harness.

[...]

>
>>
>> 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.
>
> We can let it run for 48 hours continuously every weekend using the
> Gitlab runners

Great idea. Anyways, I need to add option to limit runtime to the fuzzer
and invent some method for reporting discovered crashes to the CI first.

>
>> I am certainly going to implement this, but this is a separate topic,
>> because it quires changes in the fuzzer app. Speaking on which... Right
>> now both fuzzer and test harness reside in our github repo, as you
>> noticed. I believe it is better to host it on xenbits as an official
>> part of the Xen Project.
>
> Yes we can create repos under gitlab.com/xen-project for this, maybe a
> new subgroup gitlab.com/xen-project/fuzzer

Good. Whom should I ask to do this?

--
WBR, Volodymyr