Some devices isolate CPUs under low battery. It causes
low performance and 5 sec timeout is soemtimes too short
for dm device ready.
Bug: 267989884
Change-Id: I52e1140b961ac42401a409e3264a5facc0f60cc4
Signed-off-by: Masaya Takahashi <masaya.a.takahashi@sony.com>
We should not delete keys, once the first one was created.
Bug: 197782466
Change-Id: Ia895c140aa16553b422748531b01931737a0ea94
Signed-off-by: Jaegeuk Kim <jaegeuk@google.com>
When userdata partition is the type of ext4, checkpoint and metadata
encryption are enabled, boot up the images, if the slot currently
in use is not marked as "successful" and userdata is wiped, a reboot
will be triggered because of "Checkpoint commit failed"
In this patch, do not create checkpoint when the preceding condition
occurs, otherwise "dm-default-key" sits below "dm-bow".
Because cp_needsCheckpoint(), cp_prepareCheckpoint() and cp_commitChanges()
are always executed when the system boots up, and now there is a condition
that BOW device is not created while the slot in use is not marked as
"successful", set "isBow" to be "false" if BOW state fails to be set to
1, if "isBow" is false, then there is no need to commit the checkpoint,
and the system won't automatically reboot.
Bug: 193457319
Test: i.MX 8M Plus EVK, images flashed to board, misc and userdata
partitions are wiped, checkpoint and metadata encryption are
enabled for ext4 userdata partition.
Signed-off-by: faqiang.zhu <faqiang.zhu@nxp.com>
Change-Id: I4ad47a9504f1be0407f0fd196001a0e96919be33
DM_DEV_CREATE no longer creates sysfs nodes as of Linux kernel 5.15. It
is now necessary to DM_TABLE_LOAD as well.
Bug: 259328366
Test: userdata mounts
Change-Id: I0f88afdf95a97d44eb365e4302bbfdc7c28c0bcb
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
There have been two bugs where people use !metadata_encryption.empty()
to check whether metadata encryption is enabled. It should actually be
!metadata_key_dir.empty(), since 'metadata_encryption' is the encryption
options, which can be empty if the defaults are sufficient.
Rename the field in FstabEntry appropriately.
To avoid breaking fstab files, don't rename the flag in the fstab file
itself. So, now the fstab flags map to FstabEntry fields as follows:
keydirectory => metadata_key_dir
metadata_encryption => metadata_encryption_options
Change-Id: I3b5e28c273950bcf13bfd433aaaa49d1e92e177c
Now that FDE support has been removed, encrypt_inplace() is only used by
metadata encryption, which passes false for the set_progress_properties
parameter. Therefore, remove the set_progress_properties parameter and
the associated code to update the "vold.encrypt_inplace" and
"vold.encrypt_time_remaining" system properties.
Note that encrypt_inplace() still keeps track of its progress to some
extent, for the purpose of printing log messages; that hasn't changed.
Bug: 208476087
Change-Id: If695db1c4e23f568ff865bccc9fc1b98148815be
We need to load the partition table before we can wait on the userdata
dm device because the kernel (as of [1] doesn't send the KOBJ_ADD uevent
until after the partition table is loaded. The new flow needs to be:
CreateDevice() -> ioctl(DM_DEV_CREATE)
LoadTableAndActivate() -> ioctl(DM_TABLE_LOAD)
WaitForDevice()
This patch updates create_crypto_blk_dev() to first call
LoadTableAndActivate() before WaitForDevice().
[1] https://lore.kernel.org/all/20210804094147.459763-8-hch@lst.de/
Fixes: 156d9d2293 ("Pre-create userdata metadata encryption device.")
Bug: 210737958
Test: manually test booting raven with android13-5.15
Change-Id: Iab2214a62d44ba7e53b57f2cf0f08ac06c77b4fd
This patch adds more error logging to mountFstab. In a few cases, the
were error paths with no existing error logs. In other cases, the log
messages are there to help understand error flow in logs (for example
when a function with lots of error paths returns false).
Bug: 205314634
Test: treehugger builds
Change-Id: I464edc6e74ea0d7419ee9d9b75fd238752c13f4f
CreateDevice() implicitly calls WaitForDevice(), which can impact boot
time if there are many uevents waiting to be processed. To alleviate
this, create an empty "userdata" device when vold starts (if metada
encryption is enabled). When it comes time to actually enable metadata
encryption, the device can be re-used and the subsequent Wait should be
much faster.
Bug: 198405417
Test: manual test; device boots
Change-Id: Iaacd10858272f17353475e25075ea1dda13f8fc4
Currently, the vold detects the factory reset by checking the
metadata encryption key. This logic is only valid when the
device is not in DSU mode.
Bug: 199222795
Test: run DSU installation on a Pixel device
Change-Id: Ib40bd44d2ef7c872eba177c9ccfefac8934a49e6
Where metadata encryption is enabled, if there is no metadata encryption
key present and we are generating one anew, then there has been a
factory reset, and this is the first key to be generated. We then call
deleteAllKeys to ensure data from before the factory reset is securely
deleted.
This shouldn't really be necessary; the factory reset call itself
should be doing this. However there are currently three factory reset
paths (settings, recovery, fastboot -w) and it is not clear that all
three are doing this correctly on all devices. Obviously an attacker
can prevent this code from being run by running a version of the OS
that does not include this change; however, if the bootloader is
locked, then keys will be version bound such that they will only work
on locked devices with a sufficiently recent version of the OS. If
every sufficiently recent signed version of the OS includes this change
the attack is defeated.
Bug: 187105270
Test: booted Cuttlefish twice, checked logs
Change-Id: I9c5c547140e8b1bbffb9c1d215f75251f0f1354e
I thought it was OK to use "using" in a header file so long as it was
inside a "namespace" block, but it just imports symbols from one
namespace into another, so things that shouldn't work do.
Test: Treehugger
Change-Id: I4d43d35339636af7e95761cada7120b4db638c01
Now that vold uses Keystore2 rather than the Keymaster HAL directly, and
also the new version of Keymaster is called "KeyMint" instead, replace
most of the references to Keymaster in vold with Keystore.
(I decided not to include the "2" in most places, as it seemed
unnecessarily precise in most places, and it would be something that
might need to keep being updated. Only Keystore.{cpp,h} really need to
care about the version number.)
I didn't rename many things in cryptfs.cpp, as that file will be going
away soon anyway. I also left "wait_for_keymaster" and "vdc keymaster
earlyBootEnded" as-is for now, as those are referenced outside vold.
Bug: 183669495
Change-Id: I92cd648fae09f8c9769f7cf34dbf6c6e956be4e8
vold creates some directories for storing encryption keys if they don't
already exist, potentially including parent directories:
/metadata/vold/metadata_encryption
/data/misc/vold/volume_keys/$volume_uuid
/data/misc_de/$user/vold/volume_keys/$volume_uuid
/data/misc_ce/$user/vold/volume_keys/$volume_uuid
Currently fs_mkdirs() is used for this. However, fs_mkdirs() doesn't
include the fsync()s of the parent directories that are needed to ensure
that the new directories are persisted to disk right away -- which is
important for encryption keys.
Add a utility function MkdirsSync() which does what is needed, and make
the appropriate places call it.
Test: Booted and checked log for "Created directory" message.
Also ran 'atest vold_tests' to run the new unit test.
Change-Id: Ie9917b616433080139b8db3fd6877203ee6faf77
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
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
Commit 87999173dd ("Don't corrupt ssd when encrypting and power
fails") added a lot of code to handle pausing in-place conversion from
unencrypted => FDE when the battery was low, and resuming it later.
It was eventually decided that this wasn't needed, and commit
7e17e2d226 ("Don't worry about battery levels when encrypting")
removed the checks for low battery.
This made the partial encryption code unused. So remove it.
Note that this was cluttering up the metadata encryption code too, since
EncryptInplace.cpp is now shared by both FDE and metadata encryption.
Bug: 16868177
Test: see I08fc8465f7962abd698904b5466f3ed080d53953
Change-Id: Ibd2eb08a2aa15938097abcb8a67b5a813c4d76c7
As per the discussion at http://aosp/1456266, the retry loop in
create_crypto_blk_dev() doesn't appear to be needed. Remove it.
For now don't bother removing the same retry loop in cryptfs.cpp, since
the FDE code isn't really being updated anymore and eventually will be
removed entirely.
Change-Id: Iba0b046f9cdd9723ea1a2ae70f4d4aed4355b97b
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
Using the regular CreateDevice() variant with getDmDeviceByName() has a
race-condition that is documented in libdm/dm.h; instead, use the
variant with a timeout, which guarantees that the block device exists
when it returns.
Test: atest AdoptableHostTest
Bug: 150935323
Change-Id: Ic06cad9af7c44e23359d95b262f68dba27ddfb3a
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
