stretchSecret() no longer uses the "salt" parameter, so remove it and
simplify callers
Bug: 181910578
Test: Cuttlefish boots.
Change-Id: Ic2d0742b22b98a66da37f435e274c9d385b8e188
Vold currently uses AServiceManager_getService() to connect to
keystore2, which has an internal timeout of 5s. Since a lot of vold
keystore2 connection failures are fatal, we instead use
AServiceManager_waitForService(), which will wait efficiently for
keystore2 to start, instead of timing out after 5s.
Bug: 185934601
Test: Cuttlefish boots.
Change-Id: Ib4e977a997e020082382e0686f448d1aa72834ec
In wait_and_unmount(), kill the processes with open files after umount()
has been failing for 2 seconds rather than 17 seconds. This avoids a
long boot delay on devices that use FDE.
Detailed explanation:
On FDE devices, vold needs to unmount the tmpfs /data in order to mount
the real, decrypted /data. On first boot, it also needs to unmount the
unencrypted /data in order to encrypt it in-place.
/data can't be unmounted if files are open inside it. In theory, init
is responsible for killing all processes with open files in /data, via
the property trigger "vold.decrypt=trigger_shutdown_framework".
However, years ago, commit 6e8440fd50 ("cryptfs: kill processes with
open files on tmpfs /data") added a fallback where vold kills the
processes itself. Since then, in practice people have increasingly been
relying on this fallback, as services keep being added that use /data
but don't get stopped by trigger_shutdown_framework.
This is slowing down boot, as vold sleeps for 17 seconds before it
actually kills the processes.
The problematic services include services that are now started
explicitly in the post-fs-data trigger rather than implicitly as part of
a class (e.g., tombstoned), as well as services that now need to be
started as part of one of the early-boot classes like core or early_hal
but can still open files in /data later (e.g. keystore2 and credstore).
Another complication is that on default-encrypted devices (devices with
no PIN/pattern/password), trigger_shutdown_framework isn't run at all,
but rather it's expected that the relevant services simply weren't
started yet. This means that we can't fix the problem just by fixing
trigger_shutdown_framework to kill all the needed processes.
Therefore, given that the vold fallback is being relied on in practice,
and FDE won't be supported much longer anyway (so simple fixes are very
much preferable here), let's just change wait_and_unmount() in vold to
use more appropriate timeouts. Instead of waiting for 17 seconds before
killing processes, just wait for 2 seconds. Keep the total timeout of
20 seconds, but spend most of it retrying killing the processes, and
only if the unmount is still failing.
This avoids the long boot delays in practice.
Bug: 187231646
Bug: 186165644
Test: Tested FDE on Cuttlefish, and checked logcat to verify that the
boot delay is gone.
Change-Id: Id06a9615a87988c8336396c49ee914b35f8d585b
Otherwise only the pids are shown, and it's hard to tell which
processes actually got killed.
Bug: 187231646
Change-Id: Icccf60d0ad4439d702f36ace31abe092df1c69c2
Otherwise, when system removes user's volume, it will hang
as there are mounts (obb and data mounts) still remain mounted in system.
Bug: 187122943
Test: atest UserLifecycleTests#managedProfileUnlock_stopped, it's not blocked anymore
Change-Id: Ic37985f98e6cbfe4fa38b981d3332c4dfc40c5b8
Otherwise, the only sign of what went wrong may be system_server
logging a "ServiceSpecificException".
Bug: 187079978
Change-Id: I59b2ba2b0e679dfd1ec1fd8fff6790256fbfdf29
Originally it kills all the apps with obb and data mounted.
Due to recent changes, all apps will have obb and data dirs mounted
in default root namespace. Hence all apps will be killed by
by KillProcessesWithMounts().
To fix this, we also check if the dir is mounted as tmpfs,
as the default namespace one is bind mounted to lowerfs,
which app data isolation is mounted as tmpfs, so we only
kill the process that have obb dir mounted as tmpfs.
Bug: 148049767
Test: Able to boot without warnings
Change-Id: I5f862ad6f64f5df739b68ea7c9815352bae3be5c
Merged-In: I45d9a63ed47cbc27aebb63357a43f51ad62275db
Originally it kills all the apps with obb and data mounted.
Due to recent changes, all apps will have obb and data dirs mounted
in default root namespace. Hence all apps will be killed by
by KillProcessesWithMounts().
To fix this, we also check if the dir is mounted as tmpfs,
as the default namespace one is bind mounted to lowerfs,
which app data isolation is mounted as tmpfs, so we only
kill the process that have obb dir mounted as tmpfs.
Bug: 148049767
Test: Able to boot without warnings / errors
Ignore-AOSP-First: Merge it along with other CLs, will cherry-pick to
AOSP afterwards.
Change-Id: I45d9a63ed47cbc27aebb63357a43f51ad62275db
Change mounting storage data and obb flag to on by default
Test: unbundled/launcher/nexus_unit_test_multi_device_platform
Test: atest android.appsecurity.cts.ExternalStorageHostTest
Test: atest AdoptableHostTest
Test: pass cts/cts_postsubmit_cf_stable-cloud-tf
Bug: 148049767
Ignore-AOSP-First: Merge it along with other CLs, will cherry-pick to
AOSP afterwards.
Change-Id: I6391b7381699b4ffdbf715b67938bc3f79a5210c
