There are many corner cases when handling sizes that approach u64::max.
Limit the files to 16TB.
BUG=979458
TEST=Added unittest to check large disks fail
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Change-Id: I93a87c17267ae69102f8d46ced9dbea8c686d093
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1679892
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
(cherry picked from crosvm commit 93b0c02227f3acf2c6ff127976875cf3ce98c003)
Signed-off-by: Rob Bradford <robert.bradford@intel.com>
The extra % operation will be slower, but none of these divisions are in
hot paths. They are only used during setup. Many of these operations
take untrusted input from the disk file, so need to be hardened.
BUG=979458
TEST=unit tests still pass
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Change-Id: I0e93c73b345faf643da53ea41bde3349d756bdc7
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1679891
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
(cherry picked from crosvm commit eecbccc4d9d70b2fd63681a2b3ced6a6aafe81bb)
Signed-off-by: Rob Bradford <robert.bradford@intel.com>
Before this change, a corrupt or malicious qcow file could cause crosvm
to allocate absurd amounts of memory. The fuzzer found this case,
limit the L1 table size so it can't cause issues.
BUG=chromium:974123
TEST=run fuzzer locally, add unit test
Change-Id: Ieb6db6c87f71df726b3cc9a98404581fe32fb1ce
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1660890
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
(cherry picked from crosvm commit 70d7bad28414e4b0d8bdf2d5eb85618a3b1e83c6)
Signed-off-by: Rob Bradford <robert.bradford@intel.com>
Start with a valid header so the invalid cluster bits field is tested in
isolation. Before this change the test would pass even if the cluster
bits check was removed from the code because the header was invalid for
other reasons.
BUG=none
TEST=this is a test
Change-Id: I5c09417ae3f974522652a50cb0fdc5dc0e10dd44
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1660889
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
(cherry picked from crosvm commit c9f254b1921335231b32550b5ae6b8416e1ca7aa)
Signed-off-by: Rob Bradford <robert.bradford@intel.com>
qcow currently makes assumptions about being able to fit the L1 and
refcount tables in memory. This isn't necessarily true for very large
files. The new limits to the size of in-memory buffers still allow 1TB
files with default cluster sizes. Because there aren't any 1 TB
chromebooks available yet, limit disks to that size.
This works around issues found by clusterfuzz related to large files
built with small clusters.
BUG=972165,972175,972160,972172
TEST=fuzzer locally + new unit tests
Change-Id: I15d5d8e3e61213780ff6aea5759b155c63d49ea3
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1651460
Reviewed-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
(cherry picked from crosvm commit a094f91d2cc96e9eeb0681deb81c37e9a85e7a55)
Signed-off-by: Rob Bradford <robert.bradford@intel.com>
u32's get multiplied together and can overflow. A usize was being
returned, make everything a u64 to make sure it fits.
Change-Id: I87071d294f4e62247c9ae72244db059a7b528b62
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1651459
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
(cherry picked from crosvm commit 21c941786ea0cb72114f3e9c7c940471664862b5)
Signed-off-by: Rob Bradford <robert.bradford@intel.com>
Add a lower limit because cases such as eight byte clusters aren't
practical and aren't worth handling, tracking a cluster costs 16 bytes.
Also put an upper limit on the cluster size, choose 21 bits to match
qemu.
Change-Id: Ifcab081d0e630b5d26b0eafa552bd7c695821686
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1651458
Reviewed-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
(cherry picked from crosvm commit cae80e321acdccb1591124f6bf657758f1e75d1d)
Signed-off-by: Rob Bradford <robert.bradford@intel.com>
The QCOW2 format is documented here:
https://git.qemu.org/?p=qemu.git;a=blob;f=docs/interop/qcow2.txt;hb=HEAD
The only difference between v2 and v3 is the addition of some extra
fields into the header in v3 for which there are default values in v2.
This introduces a new unit test for the behaviour but it has been
manually verified by the converting the image from v3 to v2
with a command like:
qemu-img convert -O qcow2 -o compat=0.10 clear-29620-cloud.img clear-29620-cloud.img.v2
Signed-off-by: Rob Bradford <robert.bradford@intel.com>
Rather than relying on shared memory for a temporary file for QCOW
testing instead use tempfile crate to get a temporary file. The vector
cache tests also need a trivial update after the refactor.
Signed-off-by: Rob Bradford <robert.bradford@intel.com>
Add the BSD and Apache license.
Make all crosvm references point to the BSD license.
Add the right copyrights and identifier to our VMM code.
Add Intel copyright to the vm-virtio and pci crates.
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
