summaryrefslogtreecommitdiff
path: root/libutils/Unicode.cpp
diff options
context:
space:
mode:
authorTao Bao <tbao@google.com>2019-05-07 11:09:04 -0700
committerandroid-build-team Robot <android-build-team-robot@google.com>2019-05-10 21:52:50 +0000
commitdb2b53957075fc3eb19bc0f745549f816401a6a8 (patch)
tree9c451174d08535dfcedaf93d9560903af90f1c20 /libutils/Unicode.cpp
parent976fdf2ffda7056a1dd5775aef8d6ccad0626781 (diff)
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)
Diffstat (limited to 'libutils/Unicode.cpp')
0 files changed, 0 insertions, 0 deletions