tree 9c451174d08535dfcedaf93d9560903af90f1c20
parent e6ef013d2c8c1201540128d9961b73450257ab90
author Tao Bao <tbao@google.com> 1557252544 -0700
committer android-build-team Robot <android-build-team-robot@google.com> 1557525170 +0000

DO NOT MERGE Start update_verifier early in late-fs.

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 79cfc7d5a8a5c4d308fa2315f42cf17f253c09fd)