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
The new flag is used to indicate that a stub volume (external storage
volume shared with Chrome OS) is visible to Android apps.
Bug: 123377807
Bug: 142684760
Bug: 132796154
Test: Check logcat logs for StorageManagerService.mount() when the
Test: visibility setting of a removable device is toggled in Chrome OS.
Test: Confirm that the visibility setting is properly set.
Test: (Tested in R)
Change-Id: Ica69110d5667837a72a5c8693ff3bccc0f09a82d
This allow ARC to customize StubVolume implementation in vendor
partition.
Bug: 132796154
Test: Customize the implementation of StubVolume and check on device.
Ignore-AOSP-First: Will cherry-pick to AOSP.
Change-Id: I626a7ed4113b6132bb456b3258ee4a93b4f8a72e
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
This directory is used as a root for external storage on adopted storage
devices. It needs to be writable by processes holding the AID_MEDIA_RW
GID permission; in particular, it should be writable by the FUSE daemon.
On devices with sdcardfs, this was ensured automatically, because
sdcardfs presented a view of this directory that was writable, that we
could use for the FUSE daemon. But on devices without sdcardfs, the FUSE
daemon sees the raw filesystem and its permissions. This also means that
files created by the FUSE daemon will have their uid/gid set to the uid
of the FUSE daemon; to ensure these files stay writable to other system
applications that have AID_MEDIA_RW, use a default ACL to make sure the
gid stays AID_MEDIA_RW.
In particular, this fixes an issue with app cloning, where we want the
FUSE daemon of user 0 to be able to access the files of the app clone
user, and vice versa.
Bug: 154057120
Test: inspect uid/gid of /data/media/0 and contents
Change-Id: I6dfae41f9cb6a8283978b2667b02708a000f07c0
This is already on for all Pixel devices with no problems observed.
If this causes issues with a specific device (e.g. vendor apps being
unable to access their data) it can be temporarily disabled by adding
PRODUCT_PROPERTY_OVERRIDES += ro.vold.level_from_user=0
to the device.mk file. Please file a bug if that happens.
Bug: 141677108
Test: presubmits
Change-Id: Ic9da534f1a5f4c9e3bd62ea5c09a3b11ebcb33e7
Merged-In: Ic9da534f1a5f4c9e3bd62ea5c09a3b11ebcb33e7
(cherry picked from commit 763393644a)
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
Since /storage/emulated/userId isn't accessible for users != userId,
and vold should anyway try to avoid accessing the FUSE filesystem itself.
Bug: 172078780
Test: atest StorageManagerTest --user-type secondary_user
Change-Id: I98222bf844a6b7d8ec0d9873eddc71f61aa68c90
There've been reports of issues where, when a volume is ejected, the
MediaProvider process gets killed. This happens because the
MediaProvider has a file open on the volume (eg, during a scan). We do
abort the scan when the volume is ejected, however this could take some
time. So, we give MediaProvider a bit more time before getting killed,
by only looking for files open on the pass_through paths last. This
order anyway seems to make more sense - ideally we kill apps using
external storage before we unmount the pass_through path underlying it.
Bug: 171367622
Test: atets AdoptableHostTest
Change-Id: Ie8eacaa72a80ff8161ecf1e8c0243afcd890ee39
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
Remove the error-prone 'keepOld' parameter, and instead make begin()
(renamed to BeginKeymasterOp()) do all the key upgrade handling.
Don't handle /data and /metadata differently anymore. Previously, when
a checkpoint is active, key blob files were replaced on /data
immediately; only the actual Keymaster key deletion was delayed until
checkpoint commit. But it's easier to just delay the key blob file
replacement too, as we have to implement that for /metadata anyway.
Also be more vigilant about deleting any leftover upgraded keys.
Test: Tested on bramble using an OTA rvc-d1-release => master. In OTA
success case, verified via logcat that the keys were upgraded and
then were committed after the boot succeeded. In OTA failure
case, verified that the device still boots -- i.e., the old keys
weren't lost. Verified that in either case, no
keymaster_key_blob_upgraded files were left over. Finally, also
tried 'pm create-user' and 'pm remove-user' and verified via
logcat that the Keymaster keys still get deleted.
Change-Id: Ic9c3e63e0bcae0c608fc79050ca4a1676b3852ee
fsync() the cryptofd when done writing to it. Without this, any
remaining dirty pages in the crypto_blkdev's page cache (which there
might be a lot of, even as much as all the data that was written) won't
be flushed to disk until the cryptofd is closed, which ignores I/O
errors and is also after we already reported 100% completion.
There wasn't an fsync() in the original version either, so we've been
getting by without it, but it seems it should be there.
Change-Id: Idd1be3ae67ce96ecf3946b9efb9fc57414f5805a
* changes:
Refactor EncryptInplace.cpp
Correctly calculate tot_used_blocks on ext4 with uninit_bg
Fix memory leak of f2fs_info
Remove special handling for missing crypto_blkdev
Check return value of create_crypto_blk_dev()
Remove unused support for partial encryption
Refactor EncryptInplace.cpp to simplify and improve it a lot. This is
everything that didn't fit into prior commits, including:
- Share a lot more code between ext4, f2fs, and full encryption.
- Improve the log messages. Most importantly, don't spam the log with
huge numbers of messages, and don't log errors in expected cases.
Note: generate_f2fs_info() is still too noisy, but that's part of
"system/extras", not vold, so this change doesn't change that.
- When possible, do 32K reads/writes for f2fs and for full encryption,
not just for ext4. This might improve performance.
- Take advantage of C++ functionality.
- Be more careful about edge cases. E.g. if the calculation of the
number of blocks to encrypt was wrong, don't set vold.encrypt_progress
to > 99 until we're actually done.
The net change is over 200 lines removed.
Before-after comparison of log when enabling metadata encryption:
ext4 before:
I vold : Beginning inplace encryption, nr_sec: 16777216
D vold : cryptfs_enable_inplace(/dev/block/dm-8, /dev/block/by-name/userdata, 16777216, 0)
D vold : Opening/dev/block/by-name/userdata
D vold : Opening/dev/block/dm-8
I vold : Encrypting ext4 filesystem in place...
[omitted 6387 log messages]
I vold : Encrypted to sector 822084608
D vold : cryptfs_enable_inplace_ext4 success
I vold : Inplace encryption complete
ext4 after:
D vold : encrypt_inplace(/dev/block/dm-8, /dev/block/by-name/userdata, 16777216, false)
D vold : ext4 filesystem has 64 block groups
I vold : Encrypting ext4 filesystem on /dev/block/by-name/userdata in-place via /dev/block/dm-8
I vold : 50327 blocks (206 MB) of 2097152 blocks are in-use
D vold : Encrypted 10000 of 50327 blocks
D vold : Encrypted 20000 of 50327 blocks
D vold : Encrypted 30000 of 50327 blocks
D vold : Encrypted 40000 of 50327 blocks
D vold : Encrypted 50000 of 50327 blocks
D vold : Encrypted 50327 of 50327 blocks
I vold : Successfully encrypted ext4 filesystem on /dev/block/by-name/userdata
f2fs before:
I vold : Beginning inplace encryption, nr_sec: 16777216
D vold : cryptfs_enable_inplace(/dev/block/dm-8, /dev/block/by-name/userdata, 16777216, 0)
D vold : Opening/dev/block/by-name/userdata
D vold : Opening/dev/block/dm-8
E vold : Reading ext4 extent caused an exception
D vold : cryptfs_enable_inplace_ext4()=-1
[omitted logspam from f2fs_sparseblock]
I vold : Encrypting from block 0
I vold : Encrypted to block 15872
I vold : Encrypting from block 16384
I vold : Encrypted to block 16385
I vold : Encrypting from block 17408
I vold : Encrypted to block 17412
D vold : cryptfs_enable_inplace_f2fs success
I vold : Inplace encryption complete
f2fs after:
D vold : encrypt_inplace(/dev/block/dm-8, /dev/block/by-name/userdata, 16777216, false)
[omitted logspam from f2fs_sparseblock]
I vold : Encrypting f2fs filesystem on /dev/block/by-name/userdata in-place via /dev/block/dm-8
I vold : 15880 blocks (65 MB) of 2097152 blocks are in-use
D vold : Encrypted 10000 of 15880 blocks
D vold : Encrypted 15880 of 15880 blocks
I vold : Successfully encrypted f2fs filesystem on /dev/block/by-name/userdata
Test: Booted Cuttlefish with metadata encryption enabled and with the
userdata filesystem using (1) ext4, (2) f2fs, and (3) f2fs but
with EncryptInplace.cpp patched to not recognize the filesystem
and fall back to the "full" encryption case. Checked that the log
messages were as expected and that /data was mounted.
I've had no luck testing FDE yet; it doesn't work even without
these changes. Suggestions appreciated...
Change-Id: I08fc8465f7962abd698904b5466f3ed080d53953
The calculated number of blocks to encrypt is too high on ext4
filesystems that have the uninit_bg feature. This is because the
calculation assumes that all blocks not counted in bg_free_blocks_count
need to encrypted. But actually, uninitialized block groups have inode
blocks which vold doesn't encrypt since they are uninitialized, but they
are "allocated" and thus reduce bg_free_blocks_count.
Therefore, add a helper function num_base_meta_blocks_in_group() which
returns the number of blocks to encrypt in an uninitialized block group.
Use it both for the encryption and for calculating 'tot_used_blocks'.
Also compute 'tot_used_blocks' additively rather than subtractively, as
this is easier to understand.
Test: see I08fc8465f7962abd698904b5466f3ed080d53953
Change-Id: I4d2cb40291da67dd1bafd61289ccb9e6343bfda3
