Replace the current `string secret` argument to the lock/unlock of
CE storage with a `byte[]`. This is part of an effort to remove
instances of the LSKF and LSKF-derived secrets that are available
in a RAMdump -- since the strings are passed from Java, they cannot
be cleared, but `byte[]` can be.
This CL is the described argument change, and the propagation of this
change to the various functions that are called by the vold binder
functions.
Bug: 320392352
Test: Manual upgrade test:
1. Flash the device with a build not including these changes
2. Rebuild with these changes
3. Flash the device (but do not wipe) with the build including
these changes
4. See if the device boots and works normally -- if the CE
storage cannot be unlocked it will not start up and be usable
when the user logs in.
Change-Id: Icd4c925f2fd79e7533fdf9027e16f6736dbe1ab3
This reverts commit 697c6a5217.
It is reapplying the change in I0439f63fd4739bf5a6c957695cc9c3003ec89eb0.
Reason for revert: Undoing the revert (putting the change back in); after looking at the
performance bug, it seems impossible it was caused by the addition of the `@SensitiveData`
tag on IVold.
Performance bug: 331045735
Bug: 320392352
Test: launch_cvd -daemon
Change-Id: I522f63836155ea404260e89fd2f209738f37d5b3
This reverts commit da1d160074.
Reason for revert: reverting while figuring out what is causing performance bug 331045735
Change-Id: Ib306e679e65c3a585304ad4c33304c549cbb240e
Mitigate data leak across the Binder boundary to Vold, of secrets derived from the LSKF.
Specifically: the `String secret` argument to both `setCeStorageProtection` and `unlockCeStorage` is
a secret derived from the user's synthetic password.
This CL is part of an effort to wipe instances of the LSKF and
secrets derived from it, so they are not available in a RAMdump.
Bug: 320392352
Test: launch_cvd -daemon
Change-Id: I0439f63fd4739bf5a6c957695cc9c3003ec89eb0
This differs slightly from the previous API, which exists for idle
maintenance, whereas this value is intended to be displayed to users.
First, it returns remaining lifetime, rather than used lifetime. Second,
it rounds up the returned value for usabilty purposes. This isn't an
issue on Pixel (which reports at 1% granularity), but devices which
report at 10% granularity should show 100% out-of-box, which is not
possible to distinguish in the old API.
Bug: 309886423
Test: StorageManager.getRemainingStorageLifetime
Change-Id: Ic5f6ec9969667302ba8bad95b2765e2cc740bed4
createUserStorageKeys(), unlockCeStorage(), and prepareUserStorage()
have a user serial number parameter, but they don't actually do anything
with it except log it. Remove this unnecessary parameter.
Bug: 316035110
Test: presubmit
Flag: N/A, mechanical refactoring
Change-Id: I73ebae1afb2bdb7ca856b40b34ce806fdda718fe
Rename methods that refer to "user key" to be more precise about what
they mean. For more details, see the corresponding frameworks/base
changes (I202ebbfd2b4f79fedb3ed120a8ad81500c126894 and
I5894beb97823dced5954e405d779fada49c79e8d).
No change in behavior except for some changed log messages.
Flag: exempt, mechanical refactoring only
Test: presubmit
Change-Id: I9edcb557172395f4f6cf8e837efcc06fcfefb37d
StorageStatsManager.getTotalBytes currently takes the size of /data and
rounds up to known probable sizes to guess the size of internal storage.
This is not always correct.
Instead, find the device /data is on and get the size of that device.
This should give a more accurate answer.
Bug: 295358118
Test: vdc volume getStorageSize returns storage size
Change-Id: I907892041b1ce2cd72092a9877ac34c12bf3f254
When a volume is ejected from a user but not removed from the device
and mounted again by calling StorageManager#mount, the volume is
mounted for the user from which it was last ejected. This causes the
path of the mounted volume to be inaccessible to the current user.
Whenever StorageManager#mount is called, check if the
VolumeInfo#mountUserId is same as the current userId maintained by
StorageManagerService, if it is not, change the mountUserId for the
Volume to the current userId known to StorageManagerService if it
is not the primary volume and the volume is visible.
This change also fixes a bug where the volumes are unmounted for the
wrong user which causes StorageSessionController go out of sync
which would cause errors during mounting the volumes again as it
maintains sessions per user. The bug also caused volume event
broadcasts to be sent to wrong user handles. To solve the issue
add an extra paramter in IVoldListener#onVolumeStateChanged for userId
which will update the copy which is used for informing
StorageSessionController and also for sending broadcasts.
Test: Perform the following steps:
1. Format SD Card as portable storage in system user.
2. Eject the SD Card from Storage Settings.
3. Switch to a non-system user
4. Mount the SD Card again.
5. Check that the Storage Summary is shown correctly instead
of 0B out of 0B.
Also, checked from the logs the volume state broadcasts are sent to
the correct user handles.
Change-Id: I60b8954cdaee4a54ea6a6299fe5ddda2006faf1c
With the way the FUSE mount point are currently setup for emulated
volumes, there can be multiple paths that serve the same files on the
lower filesystem; eg
* /mnt/user/0/emulated/0/Android
* /mnt/user/10/emulated/0/Android
both refer to the same file on the lower filesystem:
* /data/media/0/Android
this is normally not a problem, because cross-user file access is not
allowed, and so the FUSE daemon won't serve files for other users.
With clone profiles this is no longer true however, as their volumes
are accessible by each other.
So, it can happen that an app running in clone profile 10 accesses
"/mnt/user/10/emulated/0/Android", which would be served by the FUSE
daemon for the user 10 filesystem.
At the same time, an app running in the owner profile 0 accesses
"mnt/user/0/emulated/0/Android", which would be served by the FUSE
daemon for the user 0 filesystem.
This can cause page cache inconsistencies, because multiple FUSE daemons
can be running on top of the same entries in the lower filesystem.
To prevent this, use bind mounts to make sure that cross-profile
accesses actually end up in the FUSE daemon to which the volume
belongs: "/mnt/user/10/emulated/0" is bind-mounted to
"/mnt/user/0/emulated/0", and vice-versa.
Bug: 228271997
Test: manual
Change-Id: Iefcbc813670628b329a1a5d408b6126b84991e09
When generating a CE key, don't persist it immediately with
kEmptyAuthentication. Instead, cache it in memory and persist it later
when the secret to protect it with is given. This is needed to make it
so that the CE key is always encrypted by the user's synthetic password
while it is stored on-disk. See the corresponding system_server changes
for more information about this design change and its motivation.
As part of this, simplify vold's Binder interface by replacing the three
methods addUserKeyAuth(), clearUserKeyAuth(), and
fixateNewestUserKeyAuth() with a single method setUserKeyProtection().
setUserKeyProtection() handles persisting the key for a new user or
re-encrypting the default-encrypted key for an existing unsecured user.
Bug: 232452368
Ignore-AOSP-First: This depends on frameworks/base changes that can only
be submitted to internal master, due to conflicts.
Test: see Ia753ea21bbaca8ef7a90c03fe73b66c896b1536e
Change-Id: Id36ba8ee343ccb6de7ec892c3f600abd636f6ce5
We introduce a new parameter of target dirty segment ratio,
which can be used to set a target dirty / (dirty + free) segments
ratio. For example, if we set this as 80%, GC sleep time will be
calculated to achieve this ratio in a GC period.
Test: check smart idle maint log of StorageManagerService
Signed-off-by: Daeho Jeong <daehojeong@google.com>
Change-Id: I73f2bcf4bdb810164c174bd0d2518b15d577d5d5
Note that, encrypt_inplace cannot support zoned device, since it
doesn't support in-place updates. And, dm-default-key will have
a different key.
Bug: 172378121
Signed-off-by: Jaegeuk Kim <jaegeuk@google.com>
Change-Id: I34cb1e747e0f3faa07c5a4bfeded11fb789a033c
* changes:
vold: remove overprovision area from free segments
vold: do not set gc sleep time with zero dirty segments
vold: add gc period in setGCUrgentPace
Now that none of these methods are used anymore, we can remove them.
Also remove the related constants.
Bug: 208476087
Change-Id: I1f56c8e05fb3fba09aab4bf5f8609b0f552b8999
To make gc period changable, added a new gcPeriod parameter to
setGCUrgentPace.
Test: adb shell device_config put storage_native_boot smart_idle_maint_period 10
Bug: 202283480
Bug: 181079477
Signed-off-by: Daeho Jeong <daehojeong@google.com>
Change-Id: I4e44a80ea5b51d9a7cde69d25e129dd0673b271f
These are no longer used.
Test: atest com.android.server.locksettings
Bug: 184723544
Change-Id: I6160d30deb138a5366532de84cbf6f02cbc69b8c
(cherry picked from commit 5bb9faab49)
Merged-In: I6160d30deb138a5366532de84cbf6f02cbc69b8c
Mounting encrypted OBB files has never worked reliably across devices,
partly due to its reliance on Twofish encryption support in the kernel.
This is because Twofish support (CONFIG_CRYPTO_TWOFISH) has never been
required or even recommended for Android. It has never been enabled in
GKI, but even before GKI it wasn't required or recommended. Moreover,
this is now the only Android feature that still uses dm-crypt
(CONFIG_DM_CRYPT), and some devices don't have that enabled either.
Therefore, it appears that this feature is unused. That's perhaps not
surprising, considering that the documentation for OBBs
(https://developer.android.com/google/play/expansion-files) says that
they are deprecated, and also it explains OBBs as being app files that
are opaque to the platform; the ability of the platform to mount OBBs
that happen to be in a particular format is never mentioned. That means
that OBB mounting is probably rarely used even with unencrypted OBBs.
Finally, the usefulness of OBBs having their own encryption layer (in
addition to what the platform already provides via FBE) is not clear
either, especially with such an unusual choice of cipher.
To avoid the confusion that is being caused by having the broken code
for mounting encrypted OBBs still sitting around, let's remove it.
Test: atest StorageManagerTest # on Cuttlefish
Test: atest StorageManagerIntegrationTest # on Cuttlefish
Bug: 216475849
Change-Id: Iaef32cce90f95ea745ba2b143f89e66f533f3479
Added interfaces required by smart idle maintenance service in
StorageManagerService, whose goal is to determine when to trigger
filesystem defragmentation while keeping the best user experience
as long as possible, and avoiding hurting UFS lifetime.
Test: check smart idle maintenance log every hour
Bug: 202283480
Bug: 181079477
Signed-off-by: Daeho Jeong <daehojeong@google.com>
Change-Id: I012cfb9b01e5d21ec71700c3c52ac9c096cd1a90
IVold.MOUNT_FLAG_VISIBLE is split into MOUNT_FLAG_VISIBLE_FOR_READ and
MOUNT_FLAG_VISIBLE_FOR_WRITE.
Accordingly, VolumeBase::MountFlags::kVisible is split into
kVisibleForRead and kVisibleForWrite.
Bug: 206019156
Test: m
Change-Id: Ia55673400d9f713f221650e1335a46ba11f6f027
Merged-In: Ia55673400d9f713f221650e1335a46ba11f6f027
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
E.g. during installation to protect the system.
Ignore-AOSP-First: this depends on changes to framework and/or incfs and does not make sense without them. We'll merge it at a single large scale merge later.
Bug: 160635296
Test: atest PackageManagerShellCommandTest PackageManagerShellCommandIncrementalTest IncrementalServiceTest PackageManagerServiceTest ChecksumsTest
Change-Id: I5851e1e9dbc8e8c2b331c407002cf7133bf6e35a
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
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
We want various per-user directories to have their SELinux MLS level
set to restrict access from other users, as an improvement to user
isolation.
We extend vold_prepare_subdirs to implement this if a flag is
set. vold itself then sets the flag based on a new property,
ro.vold.level_from_user. This is to allow testing of further
incremental work to ensure system apps correctly handle the new
restriction on different devices rather than causing immediate
breakage. Eventually this will go away and the restriction will apply
everywhere.
Bug: 141677108
Test: Manual, with and without propery set.
Change-Id: I8e2207bd94b487bdcc09fd4d80b031027dfea1e3
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
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
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
