The name "pre_gki_level" is causing some confusion because not all
devices launching with Android R are subject to the GKI requirement.
(See b/161563110#comment11.) E.g., devices that use a 4.14-based kernel
are exempt from GKI. However, the encryption requirements still apply.
Just use __ANDROID_API_Q__ directly instead.
No change in behavior.
Change-Id: Id02ae1140845ac1ae7cf78be4e57fe34da028abf
Bug: 152150018
Test: Cuttlefish with and without keydirectory option
Cherry-Picked-From: 94abae03a9
Merged-In: I400873ec207cb63f0407fefc83962bb3a927e294
Change-Id: I400873ec207cb63f0407fefc83962bb3a927e294
Vold incorrectly sends the earlyBootEnded signal only to the Keymaster
instance used for device encryption, but all of them need it.
Bug: 152932559
Test: VtsHalKeymasterV4_1TargetTest
Merged-In: Id8f01a1dc7d2398395f369c3ea74656a82888829
Change-Id: Id8f01a1dc7d2398395f369c3ea74656a82888829
To make it easier to support disk formats created using old versions
of dm-default-key with new kernels, choose the disk format to use
based on options_format_version and first_api_version properties
instead of checking the version number of the kernel module.
Bug: 150761030
Test: crosshatch and cuttlefish boot normally; cuttlefish
fails with "default-key: Not enough arguments" as expected when
option is set to 1
Change-Id: Ib51071b7c316ce074de72439741087b18335048c
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
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
More consistency between MetadataCrypt and cryptfs, and steps towards
supporting Adiantum properly in MetadataCrypt.
Test: create private volume on Cuttlefish
Bug: 147814592
Change-Id: Ic3993c1fde11b4f5a9e6cc8ee588a7d92241c6ab
To prevent keys from being compromised if an attacker
acquires read access to kernel memory, some inline
encryption hardware supports protecting the keys in
hardware without software having access to or the
ability to set the plaintext keys. Instead, software
only sees "wrapped keys", which may differ on every boot.
'wrappedkey_v0' fileencryption flag is used to denote
that the device supports inline encryption hardware that
supports this feature. On such devices keymaster is used
to generate keys with STORAGE_KEY tag and export a
per-boot ephemerally wrapped storage key to install it in
the kernel.
The wrapped key framework in the linux kernel ensures the
wrapped key is provided to the inline encryption hardware
where it is unwrapped and the file contents key is derived
to encrypt contents without revealing the plaintext key in
the clear.
Test: FBE validation with Fscrypt v2 + inline crypt + wrapped
key changes kernel.
Bug: 147733587
Change-Id: I1f0de61b56534ec1df9baef075acb74bacd00758
Just before mounting partition(s) not verified by verified boot, vold
should notify keymaster that early boot has ended so it won't allow
EARLY_BOOT_ONLY keys to be created or used.
Test: VtsHalKeymasterV4_1TargetTest
Change-Id: I74ffec8d5b33f01e62f845a8fc824b3a3cad50f3
Merged-In: I74ffec8d5b33f01e62f845a8fc824b3a3cad50f3
Version 2 of dm-default-key has an extra parameter and always sets the
DUN.
Bug: 147814592
Test: Cuttlefish boots with keydirectory flag
Test: Crosshatch formatted before this change boots after it
Change-Id: I59081e385324d2e34a5f252286a97938d6ffb79b
In case of userspace reboot, this function will be called again to
remount userdata into checkpoint mode.
Test: adb shell setprop sys.init.userdata_remount.force_umount_f2fs 1
Test: adb shell /system/bin/vdc checkpoint startCheckpoint 1
Test: adb reboot userspace
Test: adb shell dumpsys activity
Bug: 135984674
Bug: 143970043
Change-Id: I300b1960a6c4e95b13c43d806c4f3a9e4a612ac4
When both ext4 user data checkpoints and metadata encryption are
enabled, we are creating two stacked dm devices. This had not been
properly thought through or debugged.
Test: Enable metadata encryption on taimen (add
keydirectory=/metadata/vold/metadata_encryption to flags for userdata in
fstab.hardware)
Unfortunately metadata is not wiped by fastboot -w, so it is
necessary to rm metadata/vold -rf whenever you wipe data.
fastboot flashall -w works
fastboot reboot -w works
A normal boot works
Disable checkpoint commits with
setprop persist.vold.dont_commit_checkpoint 1
vdc checkpoint startCheckpoint 10
adb reboot
wait for device to fully boot then
adb reboot
Wait for device to fully boot then
adb logcat -d | grep Checkpoint shows the rollback in the logs
This tests encryption on top of checkpoints with commit, encryption
without checkpoints, and rollback, which seems to be the key cases.
Bug: 135905679
Change-Id: I8365a40298b752af4bb10d00d9ff58ce04beab1f
This mostly 1:1 replaces manual ioctls to device-mapper with calls to
libdm. There were two exceptions:
(1) There is a very old table-load-retry loop to workaround issues with
umount (b/7220345). This loop has been preserved, however, it now
includes DM_DEV_CREATE as well as DM_TABLE_LOAD.
(2) There was some ancient code to set DM_DEV_GEOMETRY for obb
dm-devices. This never did anything since geometry must be set after
loading a table. When setting it before (as vold was doing), the
subsequent DM_TABLE_LOAD will clear it.
Bug: 132206403
Test: FBE device boots
FBE device w/ metadata encryption boots
FDE device boots
atest StorageManagerIntegrationTest
Change-Id: Ib6db6b47329f093ac7084edaf604eddace8b9ac6
cryptfs.cpp and MetadataCrypt.cpp can use android::vold::sFsckContext directly.
hash.h is unuseful.
Test: make
Change-Id: I7acdac97d6ed1c9b2a5dc367fcea8aa2942192e8
This adds the ability to upgrade a key and retain the
old one for rollback purposes. We delete the old key
if we boot successfully and delete the new key if we
do not.
Test: Enable checkpointing and test rolling back
between two versions
Bug: 111020314
Change-Id: I19f31a1ac06a811c0644fc956e61b5ca84e7241a
We support file-based encryption on both ext4 and f2fs now, and the
kernel API is the same. So rename things appropriately in vold:
e4crypt => fscrypt
ext4enc => fscrypt
Ext4Crypt => FsCrypt
EXT4_* => FS_*
ext4_encryption_key => fscrypt_key
Additionally, the common functions shared by 'vold' and 'init' are now
in libfscrypt rather than ext4_utils. So update vold to link to
libfscrypt and include the renamed headers.
Note: there's a chance of 'fscrypt' being confused with the dm-crypt
based encryption code in vold which is called 'cryptfs'. However,
fscrypt is the name used in the kernel for ext4/f2fs/ubifs encryption,
and it's preferable to use the same name in userspace.
Test: built, booted device with f2fs encryption
Change-Id: I2a46a49f30d9c0b73d6f6fe09e4a4904d4138ff6
Helpers to get a block device size in bytes or 512 byte sectors,
using BLKGETSIZE64 and returning value of uint64_t type.
This also removes get_blkdev_size().
Test: build, manual, mount exFAT volume
Bug: 80202067
Change-Id: Ib07e8ac6ef7ff49de0ed570d1fa202e8b558b80c
Checkpointing uses a combination of files on the meta partition
and the checkpoint= fs_mgr flag. Checkpointed partitions will
revert to their starting state on reboot unless checkpoint commit
is called.
Test: Run vdc commands, check file on metadata
Merged-In: Icba16578608a6cbf922472e9d4ae5b8cf5f016c6
Change-Id: Icba16578608a6cbf922472e9d4ae5b8cf5f016c6
Don't use the FDE flow to support metadata encryption; just provide a
vold service which directly mounts the volume and use that.
Bug: 63927601
Test: Boot Taimen to SUW with and without metadata encryption.
Change-Id: Ifc6a012c02c0ea66893020ed1d0da4cba6914aed
std::vector with custom zeroing allocator is used instead of
std::string for data that can contain encryption keys.
Bug: 64201177
Test: manually created a managed profile, changed it's credentials
Test: manually upgraded a phone with profile from O to MR1.
Change-Id: Ic31877049f69eba9f8ea64fd99acaaca5a01d3dd
Android has a standard way to do what AutoCloseFD.h does, so use that
instead. Refactor before work on the bug.
Bug: 36029169
Test: Deleted a user and checked that secdiscard logs looked good.
Change-Id: I5d8bedfb3fa1f032fd2bced88b1b561e4a8c2ff4
Bug: 26778031
Test: Boots, reboots, sector 0 of userdata encrypted
Make sure an FDE device, both default and password protected,
boots.
Make sure an FBE device without metadata encryption boots.
Change-Id: Ic44a32ce7e9b978e9c9e2dc112b26206741c838d
Support encrypting metadata in /userdata using the dm-default-key
driver with a key in the /metadata partition.
Bug: 29189559
Test: Angler & Marlin build and boot
Change-Id: I716b117508d4bb4f6a4039293acb848cbc60f67b
