cloud-hypervisor: Collect all fuzzers automatically

[liuw]

No description provided.

[github-actions]

liuw is either the primary contact or is in the CCs list of projects/cloud-hypervisor.
liuw has previously contributed to projects/cloud-hypervisor. The previous PR was #10034

[liuw]

@likebreath do you know why the coverage build failed? It complained that the x86emul binary is not available.

A few things I don't understand:

1. In the failed task, the build script uses -O but the log shows that it still builds the dev profile.
2. Even with the dev profile, there are binaries under release.
3. The other job build (libfuzzer, address, x86_64) passes.

The only explanation I have right now is that task somehow disregards --features mshv_emulator.

[liuw]

@likebreath do you know why the coverage build failed? It complained that the x86emul binary is not available.

A few things I don't understand:

1. In the failed task, the build script uses -O but the log shows that it still builds the dev profile.
2. Even with the dev profile, there are binaries under release.
3. The other job build (libfuzzer, address, x86_64) passes.

The only explanation I have right now is that task somehow disregards --features mshv_emulator.

I work around the issue by always building x86emul.

[vitorguidi]

@rbradford can I go ahead and merge?

[rbradford]

@vitorguidi Yes - please go ahead. Thanks!

[likebreath]

@liuw I am glad to see this issue has been resolved. We can improve our cargo fuzz workflow to test it ahead. I believe cargo fuzz build by default only build with address sanitizer.

[liuw]

@liuw I am glad to see this issue has been resolved. We can improve our cargo fuzz workflow to test it ahead. I believe cargo fuzz build by default only build with address sanitizer.

For what it's worth, I build the coverage support for the fuzzers in a local branch. The local branch requires --features mshv_emulator to be specified.

 RUSTFLAGS="-Cinstrument-coverage " cargo +nightly-2024-07-11 fuzz build --features mshv_emulator 

This is what I run. I can see that x86emul is built. I opt to use the exact nightly compiler as oss-fuzz because the latest nightly doesn't work (building clap fails).

Obviously oss-fuzz sets far more flags than I do. Some of the flags can be causing the issue we see here.

That means unless we run oss-fuzz's build script in CH's CI, this particular issue cannot be caught.

[DavidKorczynski]

That means unless we run oss-fuzz's build script in CH's CI, this particular issue cannot be caught.

You can do this easily by way of CIFuzz: https://google.github.io/oss-fuzz/getting-started/continuous-integration/#continuous-integration