Don't call IKeystoreMaintenance::earlyBootEnded() too early on FDE
devices, so that keystore2 doesn't have to be restarted.
Bug: 192090857
Test: Tested FDE on Cuttlefish, both first and non-first boots.
Verified via log that earlyBootEnded is now called only when it
should be, and that keystore2 no longer has to be restarted.
Change-Id: I03f816db194a8276ad19ca99b3c8894e8a5fed23
Now that vold uses Keystore2 rather than the Keymaster HAL directly, and
also the new version of Keymaster is called "KeyMint" instead, replace
most of the references to Keymaster in vold with Keystore.
(I decided not to include the "2" in most places, as it seemed
unnecessarily precise in most places, and it would be something that
might need to keep being updated. Only Keystore.{cpp,h} really need to
care about the version number.)
I didn't rename many things in cryptfs.cpp, as that file will be going
away soon anyway. I also left "wait_for_keymaster" and "vdc keymaster
earlyBootEnded" as-is for now, as those are referenced outside vold.
Bug: 183669495
Change-Id: I92cd648fae09f8c9769f7cf34dbf6c6e956be4e8
This is needed so that system_server can remind itself about which users
have their storage unlocked, if system_server is restarted due to a
userspace reboot (soft restart).
Bug: 146206679
Test: see I482ed8017f7bbc8f7d4fd5a2c0f58629317ce4ed
Change-Id: I02f0494d827094bd41bcfe5f63c24e204b728595
(cherry picked from commit 1799debfd6)
HardwareAuthTokens are no longer used by vold since Android P. So remove
the auth token parameter from vold. This patch doesn't remove the token
from IVold.aidl, and the methods in VoldNativeService.cpp return an
error if a non-empty auth token is passed to them.
Bug: 181910578
Test: cuttlefish and bramble boot with patch
Change-Id: I1a9f54e10f9efdda9973906afd0a5de5a699ada5
reboot maybe cause a deadlock scenario:
1:init->vdc->vold for abort_fuse blocked on futex hold by another
vold binder_x
2:binder_x blocked in binder_ioctl_write_read wait a dead service's
response
3:dead service is exiting and schedule a deferred work for put files
in binder_vma_close, after put files is completed, the binder_x will
eventually wake up
4:kworker execute binder_deferred_work is blocked on fuse request:
crash> bt 1707
PID: 1707 TASK: ffffffe366175e80 CPU: 2 COMMAND: "kworker/2:4"
#0 [ffffff801b8b3ac0] __switch_to at ffffff962ce88a60
#1 [ffffff801b8b3b10] __schedule at ffffff962e2d3d30
#2 [ffffff801b8b3b70] schedule at ffffff962e2d3ff4
#3 [ffffff801b8b3bc0] __fuse_request_send at ffffff962d20e008
#4 [ffffff801b8b3c00] fuse_request_send at ffffff962d20deac
#5 [ffffff801b8b3c30] fuse_flush at ffffff962d217fa4
#6 [ffffff801b8b3c80] filp_close at ffffff962d0bd7b4
#7 [ffffff801b8b3cb0] put_files_struct at ffffff962d0e7658
#8 [ffffff801b8b3d30] binder_deferred_func at ffffff962dc9e60c
#9 [ffffff801b8b3d90] process_one_work at ffffff962cee761c
#10 [ffffff801b8b3e00] worker_thread at ffffff962cee7a68
#11 [ffffff801b8b3e60] kthread at ffffff962ceecc14
waiting for init abort_fuse
suggested by maco, do not acquire lock when abort fuse.
Test: reboot stress test
Change-Id: If6dd7f5e9c413a16ba047204c33d82d6ff41c4ae
Signed-off-by: lijiazi <lijiazi@xiaomi.com>
Has to be done before SystemConfig initialization to set correct
Incremental version feature.
Bug: 180010901
Test: atest PackageManagerShellCommandTest PackageManagerShellCommandIncrementalTest IncrementalServiceTest PackageManagerServiceTest ChecksumsTest
Change-Id: I262d1f06aecb481f37bf82005c85fed02c476510
With this change, vold exposes an API that may be used to bind key
storage encryption keys to a given seed value. The seed value passed to
vold must be consistent across reboots, or key storage keys will not be
derived consistently. The seed is expected to be set very early in boot,
prior to the use of any key storage encryption keys.
This feature is intended to be used for embedded applications such as
in autos, where the seed may be provided by some other component of the
system. In such systems, there is a default user that is automatically
signed in without a PIN or other credentials. By binding the file
encryption to a platform-provided seed, the default user's data gains
additional protection against removal of the Android embedded device
from the integrated system.
Bug: 157501579
Test: Set seed at startup via init.rc. Seed changes fail as expected.
Change-Id: I9b048ec5e045b84c45883724ace2356d4ef6244d
This new method will be used in new sm command.
Tests can use this so data and obb dirs are unmounted, and won't
be killed when volume is unmounted.
Bug: 148049767
Test: New sm command able to unmount app's data and obb dirs
Change-Id: Ifbc661ca510e996abd4b7ce1fb195aaa7afc37ad
Since Android R, the FUSE prop is always on and FUSE-off is no longer
supported
Test: m
Bug: 160159282
Merged-In: Ic4414b850511fe3b4fc6df3f8b736d21335db820
Change-Id: I5a7643f9ca2f37cd7f264331df76b42df31988d5
As storage is not mounted in system server, we use vold
to check if storage app data and obb directories exist instead.
We add a method in vold so it only creates app data and obb dirs
if dirs do not exist to speed up app starting time.
Bug: 160336374
Test: Data and obb directories are created when a new app is started
Change-Id: I1bd784d9c9e05463f71433fc782ac4e0c831cbf1
This allows us to determine the place where early boot ends from init.
It also allows fixing a bug where early boot wasn't ended previously on
devices without metadata encryption.
Bug: 168585635
Bug: 173005594
Test: inspect logs
Change-Id: I78775672a7d3c140e007235a10fb1d1bc816fcee
destroyDsuMetadataKey() / destroy_dsu_metadata_key() calls
android::gsi::GetDsuMetadataKeyDir() to query the DSU metadata
encryption key dir and destroy the key.
This releases the resource and allows consecutive DSU installations to
use the same key *directory*, but not the same key *blob*.
Bug: 168571434
Test: 1. Install a DSU system.
2. Boot the DSU system and reboot back to the host system.
3. Wipe the DSU installation.
4. DSU metadata key dir /metadata/vold/metadata_encryption/dsu/dsu is
destroyed.
Change-Id: Ib851177315a5a266807f46ccfd446de1848232cf
This is needed so "adb remount" can avoid writing to /data during a
checkpoint.
Bug: 157540389
Test: manual test
Change-Id: I33a691da3b99343acfc1e8ddf68a14504c3bfbe1
This can be done through binder as well as vdc, using 'vdc volume
abort_fuse'.
Bug: 153411204
Test: adb shell vdc volume abort_fuse
Change-Id: I93e46dc1cd361729cc1162c63520cf73152ea409
Vold needs to pass / accept IncFs control via Binder, so it
neeeds to get and put its internal FDs in and out. Using the new
release() function it works without extra fd duping
Bug: 153704006
Test: builds & boots
Change-Id: I64bc5b1ca9f2c69e34c3a860ed3edbe58bd9ea29
Vold now does not check caller's permission, but only accepts
transactions from system_server. And it's up to system server to do the
right thing and check permissions/appops.
Bug: b/152633648
Test: atest PackageManagerShellCommandTest PackageManagerShellCommandIncrementalTest
Test: adb shell appops set 1000 GET_USAGE_STATS deny
Change-Id: Id56c1673b135b72b3ec86e572aa4bcca3afc19ab
+ Get rid of an extra string copy in path validation function
Bug: 152349257
Test: atest vold_tests
Change-Id: I03a8cab0dd6abd7d5c9dcbbc2acb651e818e6cd8
Merged-In: I03a8cab0dd6abd7d5c9dcbbc2acb651e818e6cd8
+ Get rid of an extra string copy in path validation function
Bug: 152349257
Test: atest vold_tests
Change-Id: I03a8cab0dd6abd7d5c9dcbbc2acb651e818e6cd8
CL is a part of multi-repository topic and will be merged
to AOSP
Bug: 146080380
Test: manual
Change-Id: I09b33a34ff1ac7f6e415b7bd090c22e7df24d72d
Merged-In: I09b33a34ff1ac7f6e415b7bd090c22e7df24d72d
Also, use the pids provided by system server to remount all existing
processes, so we don't need to do the heavy and unreliable scanning in
/proc anymore.
Bug: 149548518
Test: atest AdoptableHostTest
Change-Id: Ifb5b79a3bc5438f36e0d61ec8aec96bdbc60ca13
AIDL generates optional<T> for nullable T types for C++, which is more
efficient and idomatic and easy to use.
Bug: 144773267
Test: build/flash/boot
Merged-In: I98549c8614c9152d5d45e2f1f33f2f3c31a9bbbf
Change-Id: I98549c8614c9152d5d45e2f1f33f2f3c31a9bbbf
(cherry picked from commit 3ce0ee5363)
Exempt-From-Owner-Approval: CP from master
AIDL generates optional<T> for nullable T types for C++, which is more
efficient and idomatic and easy to use.
Bug: 144773267
Test: build/flash/boot
Merged-In: I98549c8614c9152d5d45e2f1f33f2f3c31a9bbbf
Change-Id: I98549c8614c9152d5d45e2f1f33f2f3c31a9bbbf
(cherry picked from commit 0568fd287cfc0affc8e985f21da3793cdda286a3)
This can be used to fixup application directories in case they have been
created by some other entity besides vold; the main use case for this
API right now is OBB directories, which can be created by installers
outside of vold; on devices without sdcardfs, such directories and the
files contained therein are not setup correctly. This API will make sure
everything is setup the way it needs to be setup.
Bug: 146419093
Test: inspect OBB dir after install
Change-Id: I2e35b7ac2992dbb21cc950e53651ffc07cfca907
StubVolume is a volume type for ARC++ external storage. Named StubVolume
because it is managed from outside Android (not through Android kernel).
Previously, StubVolume is a diskless volume. However, as mentioned in
jsharkey@ email, a disk is needed for StubVolume to hold "kInternal"
(external storage type that is "external" from Android perspective,
but is "internal" to the device. For example shared directory from
ChromeOS to Android) and "kIndexable" (whether or not a disk should be
indexed by MediaStore).
The addition of disk means we could expose the createStubVolume API to
add a disk flags, which is also introduced in this CL.
Both kInternal and kIndexable will be introduced in separate CL.
Bug: 132796154
Test: Mount/unmount ARC++ removable device in ChromeOS.
Change-Id: I8b77fa1cf50ab38a2892272154dafdb78f079378
Move most of it into cryptfs.cpp, and include cryptfs.h in fewer files.
Bug: 147814592
Test: Treehugger
Change-Id: Ia3592d73e7abc1f07a60538e0978a3033bdea7de
CE keys were cached in vold to support untrusted reset
by a device admin, this is now supported by Locksettingservice
using synthetic password. This change requires a secret to be
provided to retrieve the CE key and re-wrap without the secret
when user removes the credential.
Test: Set credential, remove credential, swipe to none
and vice-versa.
Bug: 26948053
Merged-In: I4cb1c035a472477e70c1ff5bf0b2c3fcfad495e5
Change-Id: I4cb1c035a472477e70c1ff5bf0b2c3fcfad495e5
CE keys were cached in vold to support untrusted reset
by a device admin, this is now supported by Locksettingservice
using synthetic password. This change requires a secret to be
provided to retrieve the CE key and re-wrap without the secret
when user removes the credential.
Test: Set credential, remove credential, swipe to none
and vice-versa.
Bug: 26948053
Change-Id: I4cb1c035a472477e70c1ff5bf0b2c3fcfad495e5
vold historically offerred functionality to create directories on behalf
of others. This functionality was purely used to create app-specific
data/obb/media dirs. Make this more explicit by renaming the method to
indicate this.
Additionally, in the past, we never needed to care about the UID set on
these directories, because sdcardfs would take care of that for us
automatically. But with sdcardfs going away, we need to make sure the
UID of the app-specific directories is set correctly. Allow the caller
to pass this in as an argument.
Bug: 146419093
Test: atest FuseDaemonHostTest
Change-Id: Ibeb5fdc91b40d53583bc0960ee11c4d640549c34
Mounting a FUSE path needs two steps:
1. Mounting the filesystem
2. Starting the FUSE session in the FUSE daemon
The second part requires retriving an fd from (1) and the mount paths
and passing it to the FUSE daemon.
Previously, we'd return from the Vold mount call and mark the volume
as mounted while we scramble to do (2). This means there's a time
period where the Volume is marked as MOUNTED but not actually ready
and any IO access on the paths will hang forever. This could also be
misleading when interpreting bug reports.
Now, we block the Vold mount call until the FUSE session is started
Test: atest AdoptableHostTest
Bug: 144275217
Change-Id: I45238a31df71286f67ef1c65c711d0085d72e97f