Check if the block verification was already done
by snapuserd daemon - If so, skip the verification
process. If daemon failed to verify the block,
update_verifier will fallback and continue
the verification.
Bug: 193863442
Test: OTA
Signed-off-by: Akilesh Kailash <akailash@google.com>
Change-Id: I18946fb730376f19cce0738bd6765d5f5d0248b6
The property is set to inform kernel to do a warm_reset on the next
reboot. This is useful to persist the logs to debug device boot
failures. After the slot has been marked as boot successful, we can drop
the warm_reset flag to avoid the performance overhead on the next
reboot.
Bug: 143489994
Test: check the property is set to 0 by update_verifier
Change-Id: I722fb1906e6efa56dfc4ad7beccd5e2ba7e0ef7c
<stdint.h> for uint8_t; <stdlib.h> for free(3); <thread> for
std::thread.
Test: mmma -j bootable/recovery
Test: Run unit tests on crosshatch.
Change-Id: Id99b29b3d514f4e453983599c8b1aa6b0fab4ef8
We have already switched to the protobuf format for new builds, and
the downgrade packages will require a data wipe. So it should be safe
to drop the support for text format.
This also helps to save the issue when users sideload a package with a
pending OTA, because the new CareMap contains the fingerprint of the
intended build.
Bug: 128536706
Test: unit tests pass, run update_verifier with legacy CareMap
Change-Id: I1c4d0e54ec591f16cc0a65dac76767725ff9e7c4
This moves actually marking the slot as successful to a later point
so that on devices with checkpointing enabled we can still roll back to
the previous version if we fail to boot to the point that the checkpoint
is marked as successful.
Test: When taking an update on a checkpoint enabled device, it
defers marking the slot as successful instead of directly
marking it. Visible in logs.
Bug: 123260515
Change-Id: I7ed3595c1b0904ddbfe20d1cad4f69ecbf1ea351
The update_verifier now compares the fingerprint of a partition before
performing the blocks read. If the fingerprint of the current system property
mismatches the one embedded in the care_map, verification of this partition
will be skipped. This is useful for the possible system only updates in the
future.
Bug: 114778109
Test: unit tests pass
Change-Id: Iea309148a05109b5810dfb533d94260d77ab8540
The refactor separates out the parsing of care_map and the actual
verification of the partitions. Moreover, it skips the verification in case
of a format error in the care map.
Also, the parsing of care_map now uses the suffix of the file to
tell if it has the protobuf format or the plain text format.
Bug: 115740187
Test: unit test pass
Change-Id: I7aa32004db02af1deb7bfdc6f5bd7921eb7883e5
Switching to the protobuf format helps to make the care_map more
extensible. As we have such plans in the future, add the support to
parse the protobuf message in the update_verifier.
Bug: 77867897
Test: unit tests pass, update_verifier successfully verifies a care_map.pb
Change-Id: I9fe83cb4dd3cc8d6fd0260f2a47338fe142d3938
This allows the update_verifier in a general system image to work across
devices that have different verified boot versions (i.e. not supported /
verified boot 1.0 / verified boot 2.0 / disabled).
Bug: 78283982
Test: Run recovery_component_test on both of marlin and walleye.
Test: Generate an OTA that has this CL. Install this OTA and check the
update_verifier log during the post-reboot verification, on both
of marlin (VB 1.0) and walleye (VB 2.0).
Test: Build and flash walleye image with verified boot disabled. Check
that update_verifier marks the slot as successfully booted.
Change-Id: I828d87d59f911786531f774ffcf9b2ad7c2ca007
We have added the support for building /product partition in build
system (the CL in [1]), where /product is an optional partition that
contains system files. This CL adds the matching support if /product
needs to be verified during A/B OTA (i.e. listed in care_map file).
[1]: commit b7735d81054002961b681f4bdf296d4de2701135,
https://android-review.googlesource.com/c/platform/build/+/598454
Bug: 63974895
Test: Run update_verifier test on walleye.
Change-Id: Ia1c35e9583b8e66c98a4495b1f81a5ea7e65036f
Prior to this CL, the block verification works were assigned based on
the pattern of the ranges, which could lead to unbalanced workloads. This
CL adds RangeSet::Split() and moves update_verifier over.
a) For the following care_map.txt on walleye:
system
20,0,347,348,540,556,32770,33084,98306,98620,163842,164156,229378,229692,294914,295228,524289,524291,524292,524348,529059
vendor
8,0,120,135,32770,32831,94564,98304,98306
Measured the time costs prior to and with this CL with the following
script.
$ cat test_update_verifier.sh
#!/bin/sh
adb shell stop
adb shell "cp /data/local/tmp/care_map.txt /data/ota_package/"
for i in $(seq 1 50)
do
echo "Iteration: $i"
adb shell "bootctl set-active-boot-slot 0"
adb shell "echo 3 > /proc/sys/vm/drop_caches"
adb shell "time /data/local/tmp/update_verifier"
sleep 3
done
Without this CL, the average time cost is 5.66s, while with the CL it's
reduced to 3.2s.
b) For the following care_map.txt, measured the performance on marlin:
system
18,0,271,286,457,8350,32770,33022,98306,98558,163842,164094,196609,204800,229378,229630,294914,295166,501547
vendor
10,0,42,44,85,2408,32770,32806,32807,36902,74242
It takes 12.9s and 5.6s without and with the CL respectively.
Fixes: 68553827
Test: recovery_unit_test
Test: Flash new build and trigger update_verifier. Check the balanced
block verification.
Change-Id: I5fa4bf09a84e6b9b0975ee5f522724464181333f
'group_range_count' doesn't properly consider the pair-wise range
structure. It may split the ranges into wrong pairs if it evaluates to
an odd number.
For example, for an input range string of "6,0,2,10,12,20,22" with 4
threads, group_range_count becomes 1. It would then try to verify (0,2),
(2,10), (10,12) and (12,20). Note that (2,10) and (12,20) are not valid
ranges to be verified, and with (20,22) uncovered.
Bug: 68343761
Test: Trigger update_verifier verification. Check the number of verified
blocks against the one in care_map.txt.
Change-Id: I7c5769325d9866be06c45e7dbcc0c8ea266de714
This CL is to change update_verifier to verify blocks in parallel to
maximize storage bandwidth, it also preallocate the buffer to avoid
vector allocation within reading loop.
Test:
care_map.txt:
system
16,0,517,556,32770,33084,98306,98620,163842,164156,229378,229692,294914,295228,483544,524288,524296
vendor
8,0,119,135,32770,32831,96150,98304,98306
With CL:
init: Service 'update_verifier_nonencrypted' (pid 711) exited with status 0 waiting took 2.978424 seconds
Without CL:
init: Service 'update_verifier_nonencrypted' (pid 695) exited with status 0 waiting took 4.466320 seconds
Bug: 63686531
Test: reboot with manual insert care_map.txt
Change-Id: Idf791865f15f6ff6cad89bf7ff230ee46c6adccc
(cherry picked from commit bd9664b5a0)
Bootloaders using libavb will set androidboot.veritymode=disabled if
the "disable dm-verity" flag has been set. Additionally if the
"disable verification" flag is set androidboot.veritymode will not be
set at all. Handle both cases.
Without this fix we'll end up in a bootloop.
Test: Manually tested on a device using AVB.
Bug: 64315394
Change-Id: I8310849e347248f4a96158838310f688ecef4211
update_verifier should be backward compatible to not reject legacy
care_map.txt from old releases, which could otherwise fail to boot into
the new release.
For example, we've changed the care_map format between N and O. An O
update_verifier would fail to work with an N care_map.txt - a) we have
switched update_verifier to read from device mapper in O; b) the last
few blocks that contain metadata can't be read via device mapper. This
could be a result of sideloading an O OTA while the device having a
pending N update.
Bug: 63544345
Test: As follows on sailfish:
1. Flash the device with this CL;
2. Put a copy of N care_map.txt at /data/ota_package/. Restore the
permissions properly ('cache' group);
3. `adb reboot bootloader`;
4. `fastboot set_active <current_slot>`
5. Device boots up into home screen, with a warning in logcat that says
it has skipped legacy care_map.txt.
Change-Id: I6acc88c9e655a9245e6531f176fef7953953935f
When using AVB, PRODUCT_SUPPORTS_VERITY is not set so check for
BOARD_ENABLE_AVB as well. Also AVB sets up the root filesystem as
'vroot' so map that to 'system' since this is what is
expected. Managed to test at least that the code is at least compiled
in:
$ fastboot --set-active=_a
Setting current slot to 'a'...
OKAY [ 0.023s]
finished. total time: 0.023s
$ fastboot reboot
rebooting...
finished. total time: 0.050s
$ adb wait-for-device
$ adb logcat |grep update_verifier
03-04 05:28:56.773 630 630 I /system/bin/update_verifier: Started with arg 1: nonencrypted
03-04 05:28:56.776 630 630 I /system/bin/update_verifier: Booting slot 0: isSlotMarkedSuccessful=0
03-04 05:28:56.776 630 630 W /system/bin/update_verifier: Failed to open /data/ota_package/care_map.txt: No such file or directory
03-04 05:28:56.788 630 630 I /system/bin/update_verifier: Marked slot 0 as booted successfully.
03-04 05:28:56.788 630 630 I /system/bin/update_verifier: Leaving update_verifier.
Bug: None
Test: Manually tested on device using AVB bootloader.
Change-Id: I13c0fe1cc5d0f397e36f5e62fcc05c8dfee5fd85
Limit the size of each read to 1024 * BLOCKSIZE. (Same as the I/O limit
of each transfer command for block based OTA).
Bug: 37729708
Test: U_V sets slot successfully on sailfish, and it takes about ~20s
(no noticeable time increase)
Change-Id: I7a6cdc744fe4c0760e09e0afed75b89c16d8eac3
update_verifier should be in the cache group, not 'class'.
Also use PLOG instead of LOG if care_map.txt cannot be opened.
Bug: 36818743
Test: boot sailfish
Test: fake OTA on sailfish and verify update_verifier reads care_package
Change-Id: I0ec844cac5ef5c63b18ebee90160854fd84ee829
Update_verifier will reboot the device if it fails to read some blocks
on the care_map when veritymode=eio. Also make some partition name
changes to match the care_map.txt.
Test: Update_verifier reboots the device after read failures in eio mode.
Change-Id: Icf68e6151dee72f626a9ab72946100cf482a4e6c
For devices that are not using dm-verity, update_verifier can't verify
anything, but to mark the successfully booted flag unconditionally.
Test: Successfully-booted flag is set on devices w/o dm-verity.
Test: Successfully-booted flag is set after verification on devices w/
dm-verity.
Change-Id: I79ab2caec2d4284aad0d66dd161adabebde175b6
update_verifier used to read from system_block_device, which bypasses
dm-verity check completely. Switch update_verifier to read the corresponding
'/dev/block/dm-X' instead. U_v gets the verity block device number by
comparing the contents in '/sys/block/dm-X/dm/name'.
Bug: 34391662
Test: update_verifier detects the corrupped blocks and dm-verity trigger the reboot on Sailfish.
Change-Id: Ie5c50c23410bd29fcc6e733ba29cf892e9a07460
The getService() and registerAsService() methods of interface objects
now have default parameters of "default" for the service name. HALs
will not have to use any service name unless they want to register
more than one service.
Test: builds; verify HAL still works
In support of b/33844934
Change-Id: I5ce988128b0471384e1472298a0ae383df2b7c3e
Merged-In: I86c44aaaaf663e774c631a469ebf2b81619f89c4
Also make minor changes to android::base::ParseUint(), which accepts
std::string now.
Test: Flash an A/B device and make sure update_verifier works (by
marking the active slot as successfully booted).
Change-Id: Id6e578671cb3c87160c2b6ca717ee618ecf2342a
Test: UV logs show success in both binderized and passthrough modes.
Bug: 31864052
Change-Id: Ied67a52c458dba7fe600e0fe7eca84db1a9f2587
Signed-off-by: Connor O'Brien <connoro@google.com>
Read all blocks in system and vendor partition during boot time
so that dm-verity could verify this partition is properly flashed.
Bug: 27175949
Change-Id: I38ff7b18ee4f2733e639b89633d36f5ed551c989
Test: mma
(cherry picked from commit 03ca853a1c)
(cherry picked from commit 4bbe0c93c8)
(Fix a typo when comparing the verity mode)
(cherry picked from commit da654af606)
(Skip update verification if care_map is not found)
Clean up the recovery image and switch to libbase logging.
Bug: 28191554
Change-Id: Icd999c3cc832f0639f204b5c36cea8afe303ad35
Merged-In: Icd999c3cc832f0639f204b5c36cea8afe303ad35
[1] added a new API isSlotMarkedSuccessful() to actually query if a
given slot has been marked as successful.
[1]: commit 72c88c915d957bf2eba73950e7f0407b220d1ef4
Change-Id: I9155c9b9233882a295a9a6e607a844d9125e4c56
logd already gets started before we call update_verifier.
Bug: 26039641
Change-Id: If00669a77bf9a6e5534e33f4e50b42eabba2667a
(cherry picked from commit 45eac58ef1)
update_verifier checks the integrity of the updated system and vendor
partitions on the first boot post an A/B OTA update. It marks the
current slot as having booted successfully if it passes the verification.
This CL doesn't perform any actual verification work which will be
addressed in follow-up CLs.
Bug: 26039641
Change-Id: Ia5504ed25b799b48b5886c2fc68073a360127f42
(cherry picked from commit 1171d3a12b)
