am: 9389f389f5 -s ours
am skip reason: change_id I0cb8b6a85ae787e1ba2cdd7998a46942ca69760f with SHA1 e802d475bf is in history
Change-Id: I9fcc5843f969cbaeda85d4fb296e7416ddb1cde2
Bug: 120095226
Test: Tested by forcing /data/system/last-fstrim last modified time back
2 years & manually trigger checkpoint using 'vdc checkpoint startCheckpoint 1'
Change-Id: I0cb8b6a85ae787e1ba2cdd7998a46942ca69760f
Merged-In: I0cb8b6a85ae787e1ba2cdd7998a46942ca69760f
Signed-off-by: Sandeep Patil <sspatil@google.com>
The boot failure symptom is reproduced on Walleye devices. System boots
up after taking OTA and try to upgrade key, but keymaster returns "failed
to ugprade key". Device reboots to recovery mode because of the failure,
and finally trapped in bootloader screen. Possible scenario is:
(After taking OTA)
vold sends old key and op=UPGRADE to keymaster
keymaster creates and saves new key to RPMB, responses new key to vold
vold saves new key as temp key
vold renames temp key to main key -------------- (1) -- still in cache
vold sends old key and op=DELETE_KEY to keymaster
keymaster removes old key from RPMB ------------ (2) -- write directly to RPMB
==> SYSTEM INTERRUPTED BY CRASH OR SOMETHING; ALL CACHE LOST.
==> System boots up, key in RPMB is deleted but key in storage is old key.
Solution: A Fsync is required between (1) and (2) to cover this case.
Detail analysis: b/124279741#comment21
Bug: 112145641
Bug: 124279741
Test: Insert fault right after deleteKey in vold::begin (KeyStorage.cpp),
original boot failure symptom is NOT reproducible.
Change-Id: Ia042b23699c37c94758fb660aecec64d39f39738
Merged-In: Ib8c349d6d033f86b247f4b35b8354d97cf249d26
(cherry picked from commit a598e04a91)
Bug: 120095226
Test: Tested by forcing /data/system/last-fstrim last modified time back
2 years & manually trigger checkpoint using 'vdc checkpoint startCheckpoint 1'
Change-Id: I0cb8b6a85ae787e1ba2cdd7998a46942ca69760f
Signed-off-by: Sandeep Patil <sspatil@google.com>
am: 3654986ae5 -s ours
am skip reason: change_id Ib8c349d6d033f86b247f4b35b8354d97cf249d26 with SHA1 37c82f5c0f is in history
Change-Id: I3f8153ebd963a10b1633103ccc941389be0164ee
am: c6f4d9d5ae -s ours
am skip reason: change_id I53d252942c21365983b4f8b6e0948b1864f195c1 with SHA1 621d9b9732 is in history
Change-Id: I920346bf310aab6a16cea70d6e213fcff325134c
am: a598e04a91 -s ours
am skip reason: change_id Ib8c349d6d033f86b247f4b35b8354d97cf249d26 with SHA1 37c82f5c0f is in history
Change-Id: Ifec2d700dbe6bbe55e65e6e07003d1e77fb3dbc2
am: 2e58acb412 -s ours
am skip reason: change_id I53d252942c21365983b4f8b6e0948b1864f195c1 with SHA1 621d9b9732 is in history
Change-Id: Icdb62b1d4e6e7ca7d18df1083020d61d9b215165
We'd previously call ForceUnmount after the call to PrepareDir,
which would sometimes fail because the userspace counterpart of a
FUSE FS that was previously mounted at that mountpoint has gone
away. This is usually reproducible after a runtime restart.
Bug: 128459728
Test: Loop (adb shell start; atest MediaStore_Images_MediaTest; adb shell stop;)
Change-Id: I38d3908487123614c338266f983afb04e3ed78d4
When a user's CE key is removed, write "2" to /proc/sys/vm/drop_caches
rather than "3". This avoids unnecessarily evicting the pagecache of
in-use inodes. It's only necessary to evict the inodes of the relevant
encrypted files, and these are already sync'ed and no longer in-use.
For this mode "2" suffices, as this evicts "reclaimable slab objects",
including inodes; and evicting an inode implies evicting its pagecache.
This matches the recommendation I've made in the documentation for the
fscrypt kernel feature at
https://www.kernel.org/doc/html/latest/filesystems/fscrypt.html#online-attacks
Test: Sanity check that directories are still "locked" properly:
Unlock device with PIN. Then in adb shell: 'stop; start;
sleep 10; ls /data/data/' still shows filenames in ciphertext form.
Change-Id: I1bdf3c420ebf63e98cc314498211061ea36f2942
Use vold version of writeStringToFile which fsync files, and
manually fsync directories after initialize global DE
(cherry picked from commit a98464f688)
Bug: 71810347
Test: Build pass and reboot stress test.
Original boot failure symptom is NOT reproducible.
Change-Id: I1ca8f8cf0ccfd01075a9c33f79042e58d99aea26
Merged-In: I1ca8f8cf0ccfd01075a9c33f79042e58d99aea26
Remove static definition of writeStringToFile, and
move it from KeyStorage to Utils
(cherry picked from commit 0bd2d11692)
Bug: 71810347
Test: Build pass and reboot stress test.
Change-Id: I38bfd27370ac2372e446dc699f518122e73c6877
Merged-In: I38bfd27370ac2372e446dc699f518122e73c6877
vdc currently only prints generic binder failure status on failure.
This doesn't help debugging early boot failures at all since we don't
know which exact vdc command failed. Fix that by adding the command as
part of the failure message.
Bug: 129946805
Test: Boot cuttlefish
Change-Id: Ic2367cf592d6b5bf23d6d4b1447baa1baf41afe7
Signed-off-by: Sandeep Patil <sspatil@google.com>
getopt_long() assumes an all-zeroes 'struct option' at the end of the
array. Add it.
Fortunately this isn't causing problems in practice because vold is
always passed valid command line options...
Test: Running 'vold --foo' no longer segfaults.
Change-Id: I2cd3af501cc1aa11327a8062ec492be1d23defdf
Now that lockUserKey() will be called for every user each time the
framework is started, it's a normal case that the key being removed
doesn't exist. So downgrade the log message about being unable to find
a key from ERROR to DEBUG.
Test: build and boot, message is now debug level.
Change-Id: I2d1dce8dd8825b02982eab1c902aa10fe5b54b84
