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
'struct f2fs_info' from system/extras/f2fs_utils is supposed to be
freed using free_f2fs_info(), not just free().
Test: see I08fc8465f7962abd698904b5466f3ed080d53953
Change-Id: If6e75e5c604b40be24538b156a37cc76f4f0d4f7
This logic is no longer necessary, since the code that creates the
crypto_blkdev (create_crypto_blk_dev() in MetadataCrypt.cpp or in
cryptfs.cpp) now waits for the block device to appear before continuing.
It's also worth noting that the retry loop was only present for ext4,
not for f2fs, yet most Android devices are using f2fs these days.
Test: see I08fc8465f7962abd698904b5466f3ed080d53953
Change-Id: I173ca6cc187a810e008990dfa22aede58632db25
cryptfs_enable_internal() forgot to check the return value of
create_crypto_blk_dev(), so it was continuing to
cryptfs_enable_inplace() when creating the dm-crypt device failed, which
doesn't make sense.
Test: see I08fc8465f7962abd698904b5466f3ed080d53953
Change-Id: If9f20069d0f084150aa887a350f7c0c31a6d80f2
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
Commit 77df7f207d / http://aosp/1217657 ("Refactor to use
EncryptionPolicy everywhere we used to use raw_ref") unintentionally
made fscrypt_initialize_systemwide_keys() start specifying keepOld=true
(via default parameter value) when retrieving the system DE key, and
likewise for read_or_create_volkey() and volume keys.
As a result, if the associated Keymaster key needs to be upgraded, the
upgraded key blob gets written to "keymaster_key_blob_upgraded", but it
doesn't replace the original "keymaster_key_blob", nor is the original
key deleted from Keymaster. This happens at every boot, eventually
resulting in the RPMB partition in Keymaster becoming full.
Only the metadata encryption key ever needs keepOld=true, since it's the
only key that isn't stored in /data, and the purpose of keepOld=true is
to allow a key that isn't stored in /data to be committed or rolled back
when a userdata checkpoint is committed or rolled back.
So, fix this bug by removing the default value of keepOld, and
specifying false everywhere except the metadata encryption key.
Note that when an affected device gets this fix, it will finally upgrade
its system DE key correctly. However, this fix doesn't free up space in
Keymaster that was consumed by this bug.
Test: On bramble:
- Flashed rvc-d1-dev build, with wiping userdata
- Flashed a newer build, without wiping userdata
- Log expectedly shows key upgrades:
$ adb logcat | grep 'Upgrading key'
D vold : Upgrading key: /metadata/vold/metadata_encryption/key
D vold : Upgrading key: /data/unencrypted/key
D vold : Upgrading key: /data/misc/vold/user_keys/de/0
D vold : Upgrading key: /data/misc/vold/user_keys/ce/0/current
- Rebooted
- Log unexpectedly shows the system DE key being upgraded again:
$ adb logcat | grep 'Upgrading key'
D vold : Upgrading key: /data/unencrypted/key
- "keymaster_key_blob_upgraded" unexpectedly still exists:
$ adb shell find /data /metadata -name keymaster_key_blob_upgraded
/data/unencrypted/key/keymaster_key_blob_upgraded
- Applied this fix and flashed, without wiping userdata
- Log shows system DE key being upgraded (expected because due to the
bug, the upgraded key didn't replace the original one before)
$ adb logcat | grep 'Upgrading key'
D vold : Upgrading key: /data/unencrypted/key
- "keymaster_key_blob_upgraded" expectedly no longer exists
$ adb shell find /data /metadata -name keymaster_key_blob_upgraded
- Rebooted
- Log expectedly doesn't show any more key upgrades
$ adb logcat | grep 'Upgrading key'
Bug: 171944521
Bug: 172019387
Change-Id: I42d3f5fbe32cb2ec229f4b614cfb271412a3ed29
These ioctls take a pointer to an 'int' (or an 'unsigned int', it
doesn't matter), not an 'unsigned long'. See 'man ioctl_iflags'.
Presumably it happened to work anyway because Android only runs on
little endian platforms.
Bug: 146419093
Bug: 163453310
Change-Id: I73099dafd4ee8d497c0a754149271871a37454f6
Signed-off-by: Eric Biggers <ebiggers@google.com>
We previously only set +F for /data/media, but adopted storage needs
this as well. Instead we add support for adding attrs to PrepareDir.
Bug: 163453310
Test: sm set-virtual-disk true
follow UI setup and confirm +F on /mnt/expand/*/media
Change-Id: I08f13b57a4de3538e88b38eb95b0ac115a5a5ce8
Merged-In: I08f13b57a4de3538e88b38eb95b0ac115a5a5ce8
Generate a storage key without rollback_resistance when device doesnt
support the corresponding tag.
Bug: 168527558
Change-Id: Iaf27c64dba627a31c9cbd9178458bf6785d00251
When the idle maintenance task runs on Cuttlefish, there are several
warnings printed to logcat after the expected messages:
D vold : Starting trim of /data
I vold : Trimmed 0 bytes on /data in 36ms
D vold : Starting trim of /cache
I vold : Trimmed 58662912 bytes on /cache in 0ms
D vold : Starting trim of /metadata
I vold : Trimmed 7725056 bytes on /metadata in 12ms
D vold : Starting trim of none
W vold : Failed to open none: No such file or directory
D vold : Starting trim of /sdcard
W vold : Failed to open /sdcard: Not a directory
D vold : Starting trim of /mnt/vendor/shared
W vold : Trim failed on /mnt/vendor/shared: Inappropriate ioctl for device
This is because vold gathers the filesystems to trim from the fstab, but
it fails to exclude some entries that aren't appropriate to trim:
/dev/block/zram0 none swap defaults zramsize=75%
/tmp /sdcard none defaults,bind recoveryonly
shared /mnt/vendor/shared virtiofs nosuid,nodev,noatime nofail
These should be excluded because they are swap space, a bind mount, and
a virtual filesystem respectively.
Fix addFromFstab() to exclude the above cases.
Afterwards, the messages on Cuttlefish are:
D vold : Starting trim of /data
I vold : Trimmed 0 bytes on /data in 39ms
D vold : Starting trim of /cache
I vold : Trimmed 58662912 bytes on /cache in 0ms
D vold : Starting trim of /metadata
I vold : Trimmed 9822208 bytes on /metadata in 12ms
Change-Id: Idc575106fe6f81c737f684429d58dba4bd5478ad
vold already reads the default fstab into memory when starting up, and
the default fstab isn't allowed to change later. So in IdleMaint.cpp,
just use 'fstab_default' instead of reading it again.
This also has the advantage that fstab entries for "logical partitions"
now get a properly updated blk_device, which is needed in order to start
using blk_device to exclude virtual filesystems in addFromFstab().
Change-Id: Id6457a2b7972d01dde4bca0c5f2da86374d930af
When vold starts up, there are lots of warnings like:
W vold : Failed to LOOP_GET_STATUS64 /dev/block/loop30: No such device or address
W vold : Failed to LOOP_GET_STATUS64 /dev/block/loop29: No such device or address
W vold : Failed to LOOP_GET_STATUS64 /dev/block/loop28: No such device or address
vold is iterating through all loop devices and unbinding the file from
any vold-managed ones.
It's expected that not all loop devices have a file bound to them,
however. On these, LOOP_GET_STATUS64 fails with ENXIO.
Don't print a warning in such cases.
Change-Id: I91755259dc2c09b1869627259d1e59d5edd6f145
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
We want various per-user directories to have their SELinux MLS level
set to restrict access from other users, as an improvement to user
isolation.
We extend vold_prepare_subdirs to implement this if a flag is
set. vold itself then sets the flag based on a new property,
ro.vold.level_from_user. This is to allow testing of further
incremental work to ensure system apps correctly handle the new
restriction on different devices rather than causing immediate
breakage. Eventually this will go away and the restriction will apply
everywhere.
Bug: 141677108
Test: Manual, with and without propery set.
Change-Id: I8e2207bd94b487bdcc09fd4d80b031027dfea1e3
If one of the repeated operations specified by a command fails, report
the error to the user and don't export its metric.
Test: Manual run on physical device
Bug: 165903680
Signed-off-by: Stefano Duo <stefanoduo@google.com>
Change-Id: I3a8caeb6d878b004d89e425bc166c8505fda938a
Nothing defines CONFIG_HW_DISK_ENCRYPTION, so remove the unused code
that's conditional on it being defined.
Change-Id: Ie435e138686eb4eac47d9aa762ae06f1645a117f
A new interface, F2FS_IOC_SEC_TRIM_FILE, has been added to F2FS
filesystem to send secure discard command to a specific file,
not to block device. We can use this interface for better discard
command handling on a file basis.
[how to use F2FS_IOC_SEC_TRIM_FILE]
start: start offset in byte (should be aligned with 4096)
len: length in byte (should be aligned with 4096, except designating EOF)
-1 also means till EOF.
flags: F2FS_TRIM_FILE_DISCARD - sending secure discard command. If the
device doesn't support it, send normal
discard.
F2FS_TRIM_FILE_ZEROOUT - overwrite zero data in the file.
Bug: 140759142
Test: execute "secdiscard -- <file_path>" and check the content of file
Signed-off-by: Daeho Jeong <daehojeong@google.com>
Change-Id: I6ee44a047d291274c9d70ae5e4ccccfc06a52f89
The interface which is imported by an unstable interface is 'unstable'
as well. Until now, the ODR violation checker in aidl has omitted an
interface imported, but it will be checked, accordingly, fix the current
problem
Bug: 146436251
Test: m nothing
Change-Id: Id3c4bbc9149ba7c3e0a0d728026f02f60cb17424
Merged-In: Id3c4bbc9149ba7c3e0a0d728026f02f60cb17424
Exempt-From-Owner-Approval: cp from internal
