update_engine: Fix delta_performer_fuzzer
-Set the flag hash_checks_mandatory to true in the instance of
InstallPlan in the fuzzer. This allows the delta performer to perfom
aditional checks which prevent incosistencies between the manifest size
in the payload and the one reported by Omaha.
-Stop the fuzzer test if the Write function returns false.
-Fix a few minor typos.
BUG=chromium:1020621
TEST=cros_fuzz reproduce
clusterfuzz-testcase-minimized-update_engine_delta_performer_fuzzer
-4857426773671936
Change-Id: I43ca72a35d52d3b88453eb516ee05d64feadc764
Reviewed-on: https://chromium-review.googlesource.com/c/aosp/platform/system/update_engine/+/1919716
Auto-Submit: Andrew Lassalle <andrewlassalle@chromium.org>
Reviewed-by: Amin Hassani <ahassani@chromium.org>
Tested-by: Andrew Lassalle <andrewlassalle@chromium.org>
Commit-Queue: Andrew Lassalle <andrewlassalle@chromium.org>
diff --git a/README.md b/README.md
index 0c76926..82642f7 100644
--- a/README.md
+++ b/README.md
@@ -187,7 +187,7 @@
update engine and happen in the background. Interactive updates, on the other
hand, happen when a user specifically requests an update check (e.g. by clicking
on “Check For Update” button in Chrome OS’s About page). Depending on the update
-servers policies, interactive updates have higher priority than non-interactive
+server's policies, interactive updates have higher priority than non-interactive
updates (by carrying marker hints). They may decide to not provide an update if
they have busy server load, etc. There are other internal differences between
these two types of updates too. For example, interactive updates try to install
@@ -237,12 +237,12 @@
The update payload generation is the process of converting a set of
partitions/files into a format that is both understandable by the updater client
-(especially if it's much older versions) and is securely verifiable. This
+(especially if it's a much older version) and is securely verifiable. This
process involves breaking the input partitions into smaller components and
compressing them in order to help with network bandwidth when downloading the
payloads.
-For each generated payload, there is corresponding properties file which
+For each generated payload, there is a corresponding properties file which
contains the metadata information of the payload in JSON format. Normally the
file is located in the same location as the generated payload and its file name
is the same as the payload file name plus `.json`
@@ -389,11 +389,11 @@
## update_payload Scripts
-[update_payload] contains a set of python scripts mostly to validate payload
-generation and application. We normally test the update payloads using an actual
-device (live tests). [`brillo_update_payload`] script can be used to generate
-and test applying of a payload on a host device machine. These tests can be
-viewed as dynamic tests without the need for an actual device. Other
+[update_payload] contains a set of python scripts used mostly to validate
+payload generation and application. We normally test the update payloads using
+an actual device (live tests). [`brillo_update_payload`] script can be used to
+generate and test applying of a payload on a host device machine. These tests
+can be viewed as dynamic tests without the need for an actual device. Other
`update_payload` scripts (like [`check_update_payload`]) can be used to
statically check that a payload is in the correct state and its application
works correctly. These scripts actually apply the payload statically without
@@ -532,7 +532,7 @@
current channel, etc. However, to override any of these parameters, create the
file `/mnt/stateful_partition/etc/lsb-release` with desired customized
parameters. For example, this can be used to point to a developer version of the
-update server and allow the update_engine to schedule a periodic update form
+update server and allow the update_engine to schedule a periodic update from
that specific server.
If you have some changes in the protocol that communicates with Omaha, but you
diff --git a/payload_consumer/delta_performer_fuzzer.cc b/payload_consumer/delta_performer_fuzzer.cc
index 53b168a..73082c4 100644
--- a/payload_consumer/delta_performer_fuzzer.cc
+++ b/payload_consumer/delta_performer_fuzzer.cc
@@ -60,6 +60,7 @@
.target_path = "/dev/null",
.target_size = 4096,
}},
+ .hash_checks_mandatory = true,
};
InstallPlan::Payload payload{
@@ -81,7 +82,8 @@
do {
auto chunk_size = data_provider.ConsumeIntegralInRange<size_t>(0, 100);
auto data = data_provider.ConsumeBytes<uint8_t>(chunk_size);
- performer.Write(data.data(), data.size());
+ if (!performer.Write(data.data(), data.size()))
+ break;
} while (data_provider.remaining_bytes() > 0);
}
diff --git a/update_metadata.proto b/update_metadata.proto
index 40db678..3d136ca 100644
--- a/update_metadata.proto
+++ b/update_metadata.proto
@@ -73,7 +73,7 @@
// new partition.
// - ZERO: Write zeros to the destination dst_extents.
// - DISCARD: Discard the destination dst_extents blocks on the physical medium.
-// the data read from those block is undefined.
+// the data read from those blocks is undefined.
// - REPLACE_XZ: Replace the dst_extents with the contents of the attached
// xz file after decompression. The xz file should only use crc32 or no crc at
// all to be compatible with xz-embedded.