GuestMemory::new returns an error if the requested size is not divisible
by the page size. The zimage fuzzer was using a GuestMemory size based
on the size of the fuzzer input; however, it doesn't necessarily make
sense to limit the guest memory to the size of the input. Pick an
arbitrary 256 MB (matching the block fuzzer), which is also a page size
multiple to resolve the original issue.
BUG=chromium:977883
TEST=/usr/libexec/fuzzers/crosvm_zimage_fuzzer in cros_fuzz shell
Change-Id: I08c6be9d920bede18d67f8a1c5c39b9d37fb839c
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1645040
Tested-by: kokoro <noreply+kokoro@google.com>
When the input's length is not page aligned, round it up. This allows
the fuzzer to provide more random inputs without causing the `unwrap`
call to trigger false positives when creating guest memory.
BUG=chromium:972172
TEST=run fuzz case from the bug
Change-Id: Iaf8f2ba943f38b90e168301dbb8c15dee5ee45c8
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1659626
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
After CL:1636685, the kernel_loader API is different - we need to pass a
File instead of just a slice to load_kernel().
Borrow and adapt the make_elf_bin() function from the kernel_loader
tests to create a shared memory file from a slice of bytes to fix the
fuzzer.
BUG=chromium:970981
TEST=USE='asan fuzzer' emerge-nami crosvm
Change-Id: Ic17f6479fb355d45063ce6292552cb1e5664831a
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1645039
Reviewed-by: Zach Reizner <zachr@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
In Rust 2018 edition, `extern crate` is no longer required for importing
from other crates. Instead of writing:
extern crate dep;
use dep::Thing;
we write:
use dep::Thing;
In this approach, macros are imported individually from the declaring
crate rather than through #[macro_use]. Before:
#[macro_use]
extern crate sys_util;
After:
use sys_util::{debug, error};
The only place that `extern crate` continues to be required is in
importing the compiler's proc_macro API into a procedural macro crate.
This will hopefully be fixed in a future Rust release.
extern crate proc_macro;
TEST=cargo check
TEST=cargo check --all-features
TEST=cargo check --target aarch64-unknown-linux-gnu
TEST=local kokoro
Change-Id: I0b43768c0d81f2a250b1959fb97ba35cbac56293
Reviewed-on: https://chromium-review.googlesource.com/1565302
Commit-Ready: David Tolnay <dtolnay@chromium.org>
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: David Tolnay <dtolnay@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: David Tolnay <dtolnay@chromium.org>
This may help reduce cases of conflicts between independent CLs each
appending a dependency at the bottom of the list, of which I hit two
today rebasing some of my open CLs.
TEST=cargo check --all-features
Change-Id: Ief10bb004cc7b44b107dc3841ce36c6b23632aed
Reviewed-on: https://chromium-review.googlesource.com/1557172
Commit-Ready: David Tolnay <dtolnay@chromium.org>
Tested-by: David Tolnay <dtolnay@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Separated out of CL:1513058 to make it possible to land parts
individually while the affected crate has no other significant CLs
pending. This avoids repeatedly introducing non-textual conflicts with
new code that adds `use` statements.
TEST=cargo check
TEST=cargo check --all-features
TEST=cargo check --target aarch64-unknown-linux-gnu
Change-Id: I355014ebd08bc2a655e1a1bbff56ecc90aa99ece
Reviewed-on: https://chromium-review.googlesource.com/1519695
Commit-Ready: David Tolnay <dtolnay@chromium.org>
Tested-by: David Tolnay <dtolnay@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: David Tolnay <dtolnay@chromium.org>
Fuzz using the data as a qcow image with an offset and value to write to
the image.
Change-Id: Iff8f2971ba716c93d978e33338ad62b5d487c115
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/871132
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
There is now infrastructure for running fuzzers in cros, use it.
Change-Id: I53ec9e195b7062fdcc38b5186c1f3194031037f3
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1521667
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
These are each their own workspace so I guess `cargo fmt` at the top
level of the repo does not hit them.
I checked that none of the other workspace roots currently need to be
reformatted.
TEST=cargo check
Change-Id: I734cbc0f909fd3c2138513d9539b917bce80c0a8
Reviewed-on: https://chromium-review.googlesource.com/1477496
Commit-Ready: David Tolnay <dtolnay@chromium.org>
Tested-by: David Tolnay <dtolnay@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Add a top level fuzz directory. Other fuzz tests will be added here in
subsequent commits.
For now fuzzing must be run manually. Soon there will be a way to
extract the fuzz artifacts and upload them to cluster fuzz.
Change-Id: Iddfb55af78af6f412927b2221f22acb882069d36
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/850851
Reviewed-by: Zach Reizner <zachr@chromium.org>
