am: ebce4cc16b -s ours
am skip reason: change_id Ib3272a47a901ed106474039e72f123b11f5443ff with SHA1 5fceb48da1 is in history
Change-Id: I0d248b5b041118b318c36858882342d626fcb7b0
This trigger was used on FDE devices to bring down the minimal
framework, and worked by shutting down the 'main' service class.
With APEX being introduced, we want to restart all services that were
started after the tmpfs /data was mounted, as those are the services
that haven't been able to use updated APEXes in the (real) /data.
In order to do this, we need to reset more classes; that in turn
made the 'shutdown_main' trigger pretty much similar to the
previously existing 'trigger_shutdown_framework' trigger; so instead
of keeping two duplicate triggers, use only the
'trigger_shutdown_framework' one.
Bug: 118485723
Test: Taimen configured as FDE boots, Taimen configured as FBE boots
Change-Id: I0d80ef2528bd70870b063a2c580cd00a03de9961
This trigger was used on FDE devices to bring down the minimal
framework, and worked by shutting down the 'main' service class.
With APEX being introduced, we want to restart all services that were
started after the tmpfs /data was mounted, as those are the services
that haven't been able to use updated APEXes in the (real) /data.
In order to do this, we need to reset more classes; that in turn
made the 'shutdown_main' trigger pretty much similar to the
previously existing 'trigger_shutdown_framework' trigger; so instead
of keeping two duplicate triggers, use only the
'trigger_shutdown_framework' one.
Bug: 118485723
Test: Taimen configured as FDE boots, Taimen configured as FBE boots
Change-Id: I0d80ef2528bd70870b063a2c580cd00a03de9961
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
