When using multiple partitions, f2fs stores all the device paths, but we cannot
guarantee the dm targets are all the same across boot cycles.
Bug: 287247093
Change-Id: Ie4308a27548d4e814924afb656478cfa55fcf8b6
Signed-off-by: Jaegeuk Kim <jaegeuk@google.com>
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
* changes:
Revert "fskeyring & userspace reboot: support CE keys"
Evict adoptable storage CE and DE keys when possible
Don't erase key from s_new_ce_keys on eviction
Call fscrypt_destroy_volume_keys() under mCryptLock
Fold read_and_install_user_ce_key() into fscrypt_unlock_user_key()
Userspace reboot turned out to be a dead end and is no longer supported.
Therefore, remove the code from vold that handled keeping CE storage
unlocked past the userdata filesystem being unmounted and mounted.
This is a revert of commit 1c6731c649 (https://r.android.com/1254615)
with various conflicts resolved.
Bug: 292469129
Change-Id: If530edaf7c1566dd3bd8b1322f935f38a2e66beb
Merged-In: If530edaf7c1566dd3bd8b1322f935f38a2e66beb
(cherry picked from commit 2b97a88ba4)
Adoptable storage CE and DE keys were not being explicitly evicted,
resulting in the benefits of key eviction not being fully realized on
devices that use adoptable storage. Fix this by evicting the adoptable
storage keys when the corresponding internal storage keys are evicted:
- In lockUserKey, evict the CE keys for adoptable storage volumes, not
just the CE key for internal storage as was done before.
- In destroyUserKey, evict the user's CE and DE keys for adoptable
storage, not just the internal storage keys as was done before.
To make this possible, starting keeping track of the EncryptionPolicy of
each currently installed adoptable storage key.
(This CL is reworked from https://r.android.com/2660878,
original author Arnab Sen <arnabse@amazon.com>)
Test: On Cuttlefish with config_multiuserMaxRunningUsers changed to 1:
sm set-virtual-disk true
sm partition disk:7,416 private
pm create-user 10
am start-user 10
am stop-user 10
# Verified that this fails with "Required key not available".
touch /mnt/expand/f1ad173b-d6d9-4948-8eb7-ccdd7b053b22/misc_ce/10/foo.txt
am start-user 10
pm remove-user 10
# Checked for all the expected "Evicted fscrypt key" messages.
# 2 from when user was stopped, and 4 from when user was removed.
adb logcat | grep Evicted
Change-Id: I7f11a135d8550618cd96013f834cebd54be5ef84
Merged-In: I7f11a135d8550618cd96013f834cebd54be5ef84
(cherry picked from commit 68fd3689a1)
Erasing a key from s_new_ce_keys is equivalent to destroying it, so it
shouldn't be done when the key is merely being evicted.
This didn't matter in practice since eviction requests don't come in
before the key gets persisted, but fix this to avoid confusion.
Test: see I7f11a135d8550618cd96013f834cebd54be5ef84
Change-Id: I28412f243925b5a7242449b617fe9de9c90912b6
Merged-In: I28412f243925b5a7242449b617fe9de9c90912b6
(cherry picked from commit 3529302ede)
Everything in FsCrypt.cpp seems to run under VolumeManager::mCryptLock,
except for fscrypt_destroy_volume_keys() which uses mLock instead.
This was sort of okay because fscrypt_destroy_volume_keys() didn't
operate on any in-memory data structures. However, that is going to be
changed. Therefore, rework VoldNativeService::forgetPartition() to call
fscrypt_destroy_volume_keys() under mCryptLock.
Test: see I7f11a135d8550618cd96013f834cebd54be5ef84
Change-Id: Ia27a61faf2fdd546cdbddb2a3985c7c6696f6aa6
Merged-In: Ia27a61faf2fdd546cdbddb2a3985c7c6696f6aa6
(cherry picked from commit ce86e24d23)
No change in behavior, except for removing a redundant check of
's_ce_policies.count(user_id)' and removing an extra ERROR message.
Test: see I7f11a135d8550618cd96013f834cebd54be5ef84
Change-Id: If221e23991e8e04138ae7dbdafe8160b00893655
Merged-In: If221e23991e8e04138ae7dbdafe8160b00893655
(cherry picked from commit 92428b247f)
Generated corpus using binder2corpus tool from recordings
of vold transactions and using it with vold service fuzzer.
Test: m vold_native_service_fuzzer && adb sync data && adb shell /data/fuzz/arm64/vold_native_service_fuzzer/vold_native_service_fuzzer /data/fuzz/arm64/vold_native_service_fuzzer/vold_native_service_fuzzer_corpus -runs=1000
Bug: b/299138341
Change-Id: Ic9bc7a7971790fa19a04181b6f89a33a0088bdd8
Align units to a segment unit when adjusting free segment number.
Test: run the smart idle maint service.
Change-Id: I4fd74ac92adc4ae1a0ded4a7df75a690d829eb20
Signed-off-by: Daeho Jeong <daehojeong@google.com>
Public SdCard Volumes are mounted only for user 0
(foreground user). This gives ENONT if the cloned
user tries to access the files in SdCard with
paths like "/storage/AB02-G212/DCIM/"
This change adds SdCard Volume mnt under
/mnt/usr/<cloned-user>/ which allows cloned apps
access to SdCard via direct file paths.
Bug: 203395175
Test: Manual by building and flashing device.
Change-Id: I091c40d3cb19915145cd5af40d1e79d5a9ecfa02
We no longer support ro.apex.updatable=false case. Hence no need to read
it.
Bug: 297460439
Test: device boots
Change-Id: I9b71ea96052741073f092ca6abcfbe92a927128a
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
This reverts commit 78f806198f.
There is no code that reads this system property, logcat already shows
whether the FS keyring is being used, and all devices launching with
Android 11 and later are guaranteed to use the FS keyring anyway.
Bug: 154327249
Change-Id: Id906efedd89d5bcac5370fb141cdbf7848932d95
vold_prepare_subdirs should create apexdata directories for each APEX.
Previously, it gets the list by scanning /apex directory. However,
vold/vold_prepare_subdirs run in the bootstrap mount namespace, they can
see only bootstrap apexes in /apex. The reason why it worked was that
unintended side effects of how we managed /apex directory for both mount
namespace.
Instead, since apexdata directories are already populated by init in
/data/misc/apexdata, we can use that directory for the same purpose.
Bug: 295345486
Test: CtsPackageSettingHostTestCases
Change-Id: I453cd59f54ccbb140f73b5e8576b36fa49f9bc59
In this change, the logic to get the list of apexes is replaced with
the query to apexservice, which is the source of truth. This dedups
the manual scanning of /apex for the apex list, which should be
internal to apexd. (Note how vold_prepare_subdirs filtered out
directories with "@" character).
This also makes vold_prepare_subdirs immune to the upcoming changes:
/apex directory containing only bootstrap APEXes in the bootstrap NS.
Until now, getting the list of apexes by scanning /apex was okay
because of the accidental fact that /apex directory has directories
for all the apexes, not only bootstrap apexes.
Bug: 293949266
Bug: 293546778
Test: CtsPackageSettingHostTestCases
Change-Id: I3fe373ca6f4c2281439bb2449845a1a14357131e
Newer versions of libc++ check that an allocator can be rebound to the
same element type. We need to add a rebind member to ZeroingAllocator
to fix this compiler error:
prebuilts/clang/host/linux-x86/clang-r498229/include/c++/v1/vector:376:19: error: static assertion failed due to requirement 'is_same<android::vold::ZeroingAllocator, std::allocator<char>>::value': [allocator.requirements] states that rebinding an allocator to the same type should result in the original allocator
static_assert(is_same<allocator_type, __rebind_alloc<__alloc_traits, value_type> >::value,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
It likely doesn't matter in practice because this allocator is only
used with std::vector, which probably doesn't use allocator rebinding,
because it won't allocate an internal node type (e.g. unlike std::map,
std::list, etc).
Alternatively, ZeroingAllocator could be changed to a
ZeroingAllocator<T> that can zero arbitrary types, but it doesn't seem
necessary currently, and types other than char wouldn't be used.
Bug: b/175635923
Test: treehugger
Change-Id: I42e9d8f02a18637fc67e94cc1358d2ed733a7268
when the idlemaint run is working, if two or more idlemaint abort concurrency are working.
all idlemaint abort will hold the wakelock, until idlemaint run finished,
but it just nofity one idlemaint abort thread to stop and release the wakelock.
Remaining idlemaint abort threads will hold the wakelock until next idlemaint run to notify them.
Bug: 292383791
Test: see the issue Description
Change-Id: I5312be2e0e92c41483cab26e627a4ae562e5aed8
