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-15 05:34:29 +0000
commitcee9908b9e609b73e6d5ee3ed8deb3b8bff517fd (patch)
tree9c451174d08535dfcedaf93d9560903af90f1c20 /libutils/Unicode.cpp
parent6f2198b33cd4de28f98f8a834e4c0bd98a954c74 (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