am skip reason: Change-Id Id8616804bba622226ca21b8eff0d3eb577b4b7e0 with SHA-1 1dd5c4f787 is in history
Change-Id: I30e748f7983e661ba2abd9bbd2ec12dc453b1eb1
+ Get rid of an extra string copy in path validation function
Bug: 152349257
Test: atest vold_tests
Change-Id: I03a8cab0dd6abd7d5c9dcbbc2acb651e818e6cd8
Merged-In: 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
During userspace reboot /data might be unmounted & remounted, meaning
that CE keys stored in fs-level keyring will be lost. In order to be
able to restore them, when installing new key to fs-level keyring, it's
also added to session-level keyring with type "fscrypt-provisioning".
Then when init_user0 is called during userspace reboot, vold will try to
load CE keys from the session-level keyring back into fs-level keyring
for all the users that were unlocked before the reboot.
If for any user vold fails to install the key, init_user0 will fail and
fallback to hard reboot will be triggered.
Test: set a pin pattern
Test: adb shell setprop sys.init.userdata_remount.force_umount 1
Test: adb shell svc power reboot userspace
Test: atest CtsUserspaceRebootHostSideTestCases
Bug: 143970043
Change-Id: I37603dc136c7ededc7b0381e4d730cb0ffd912b4
Merged-In: I37603dc136c7ededc7b0381e4d730cb0ffd912b4
(cherry picked from commit 1ee35cf002)
During userspace reboot /data might be unmounted, which means that if
device supports filesystem keyring, DE keys will be lost and are needed
to be re-installed.
Test: adb shell setprop sys.init.userdata_remount.force_umount 1
Test: adb shell svc power reboot userspace
Test: atest CtsUserspaceRebootHostSideTestCases
Bug: 143970043
Change-Id: I153caa1d7c373b3c906a34f1184c681e52854a9d
Merged-In: I153caa1d7c373b3c906a34f1184c681e52854a9d
(cherry picked from commit 1eaea5a6a2)
FDE device has shut down and restart the framework.
But restart is not triggered due to umount fail.
umount /data fail with "device is busy"
It is because bind mount /data/data to /data/user/0
We need umount /data/user/0 before umount /data
Bug: 148004718
Test: Flash GSI and check boot with FDE and FBE device.
Change-Id: I919f9e31a9d2d745b297a7ab99b399aa9b293b39
fs_mgr may put other dm devices on top of the raw disk, such as for
checkpointing, and it hands metadata encryption the uppermost device in
vdc. That's what should be encrypted, not the raw disk.
Bug: 150354860
Test: Treehugger
Change-Id: I279f087b1b7aded40c5a62281154851ce970ba70
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)
Making HEH the default was always a mistake and a giant foot-gun.
Let's make life easier for people by making the default depend on
first_api_level, so it's automatically set up right for new devices
without breaking old ones. Also use v2 fscrypt keys instead of v1 post
Q.
Bug: 147107322
Test: Various Cuttlefish configurations
Change-Id: I5432bdfd6fec6ed34e7f9ab7cdd32cdeb2a03472
The dm-crypt solution requires a kernel patch that won't be present in
the GKI kernel, while the new metadata encryption system in the GKI
kernel solves this problem in a much cleaner way.
Test: create private volume on Cuttlefish, setting property both ways.
Bug: 147814592
Change-Id: Ie02bd647c38d8101af2bbc47637f65845d312cea
metadata_encryption fstab option provides details on the cipher
and flags used for metadata encryption. wrappedkey_v0 is provided
to dm-default-key dm device when a wrapped key is used. The
inline encryption hardware unwraps the key and derives the
encryption key used to encrypt metadata without returning the key
in the clear to software.
Bug: 147733587
Test: FBE with metadata encryption using wrapped keys.
Change-Id: Ibf69bdc12bb18d2f0aef8208e65f3a8dececfd2a
No need for KeyUtil to know how to make a KeyGeneration, it's cleaner
if each module handles it separately. Also, create a CryptoOptions
structure to track metadata encryption options, and simplify legacy
cipher/option handling.
Test: Treehugger
Bug: 147814592
Change-Id: I740063882914097329ff72348d0c0855c26c7aab
