c61ef45379
We used to start update_verifier after mounting userdata (post-fs-data),
as part of zygote-start. This leads to issues in practice for security
updates, where an A/B device falls back into the old slot (for any
reason, which unrelates to this change) but failing to boot due to
upgraded key blob. It essentially breaks the fallback capability offered
by A/B OTA.
This CL mitigates the issue by starting update_verifier early, before
mounting userdata. This avoids the device from falling back to the old
slot with an already-upgraded key blob. update_verifier loses the
opportunity of verifying _all_ the updated blocks based on the info
that's stored in userdata. Instead it will only trigger the minimal
read to finish the work of marking a successful boot. This is a
trade-off in P to avoid putting the device in a bad state after
fallback, which will be improved in Q by better handling the fallback
path in vold.
Bug: 131176531
Test: Flash and boot crosshatch. Check the start of update_verifier and
it marks a successful boot.
Change-Id: I3f4c4333ff38772a9a93c9d027d497db11de1d63
(cherry picked from commit
|
||
|---|---|---|
| .. | ||
| etc | ||
| Android.mk | ||
| asan.options | ||
| asan_extract.rc | ||
| asan_extract.sh | ||
| init-debug.rc | ||
| init.environ.rc.in | ||
| init.rc | ||
| init.usb.configfs.rc | ||
| init.usb.rc | ||
| init.zygote32.rc | ||
| init.zygote32_64.rc | ||
| init.zygote64.rc | ||
| init.zygote64_32.rc | ||
| OWNERS | ||
| ueventd.rc | ||