When the partition is f2fs and the OS is 32bit, the data.f_bavail and
data.f_frsize are 32 bits in size. The product of them is also 32 bits
in size. If the available size of storage is greater than 4G, the
product may be greater than the unsigned long max value. If the product
is overflow and less than 100M. The UDC feature will be disabled.
There is also an overflow for std::strtoul when the variable content
is a very big number(more the unsigned long max value).
To avoid the overflow:
1. convert the variable data.f_bavvail to uint64_t and then compute the
multiplication.
2. use std::strtoull replace to std::strtoul.
Bug: 147118861
Change-Id: I60172ae4cb7c997e2ad4a36583be74736c25e565
time_started in encryptGroupsData is set from and compared to
clock_gettime(CLOCK_MONOTONIC, ...) nearly everywhere: "Clock that
cannot be set and represents monotonic time since some unspecified
starting point". However in cryptfs_enable_inplace_f2fs() it is set
from a different clock, time(NULL), with the result that the setprop
calls that indicate progress are wrong and can be called much too
often. The fix is to make this function consistent with
cryptfs_enable_inplace_ext4.
Bug: 146877356
Change-Id: I2707180e5c5bf723a5a880f6a3aac47f2bb34ccd
- Use FSCRYPT_MAX_KEY_SIZE from <linux/fscrypt.h> instead of manually
defining FS_AES_256_XTS_KEY_SIZE. These have the same numeric value
(64), but the former is supposed to be used, and AES-256-XTS isn't
necessarily the encryption algorithm that is being used anyway.
- Use the new name FSCRYPT_KEY_DESCRIPTOR_SIZE instead of the old name
FS_KEY_DESCRIPTOR_SIZE. These have the same numeric value (8).
- Don't try to handle sizeof(fscrypt_key::raw) > FSCRYPT_MAX_KEY_SIZE,
as this simply isn't the case.
- Set fscrypt_key::mode to 0 rather than FS_ENCRYPTION_MODE_AES_256_XTS.
This field has always been ignored by the kernel, and AES-256-XTS
isn't necessarily the encryption algorithm that is being used anyway.
- Initialize the fields of fscrypt_key in order.
This is a cleanup only.
Test: booted hikey with fileencryption=aes-256-xts and a kernel that
doesn't support the new fscrypt ioctls.
Bug: none
Change-Id: Ie2a7e9240aa479dfab2765c11db8a7124d20c643
aosp/1184798 has updated the kernel headers to 5.4, so we no longer need
the file fscrypt_uapi.h. In KeyUtil.cpp we also now don't need
<linux/fs.h>, but rather just the more specific <linux/fscrypt.h>.
Test: build
Bug: None
Change-Id: I56d17826eb7c3b95c74ce0435a4feae7f3cc325e
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
This creates apexrollback directories under /data/misc_[de|ce]/<user>
which will hold snapshots of DE_n and CE_n apex data directories
(i.e. it will hold backups of data from /data/misc_[de|ce]/<user>/apexdata
for particular apexes).
See go/apex-data-directories for details.
Bug: 141148175
Test: Built and flashed, checked directory was created.
Change-Id: I468060b20dee0c50033b5f014ce8716582d5e6bc
It will be used during the userspace reboot to unmount all emulated
storages, which is a prerequisite to unmount+remount ext4 userdata into
checkpoint mode.
Test: adb shell /system/bin/vdc checkpoint startCheckpoint 1
Test: adb reboot userspace
Bug: 143970043
Bug: 135984674
Change-Id: I07491bc4be2f30debe21b764766c9def68548e16
This creates an apexdata directory under /data/misc_de/<user> and
/data/misc_ce/<user>, and also creates a directory under that for
every APEX that is installed.
See go/apex-data-directories.
APEXes are discovered by scanning the /apex directory. It may be better
to delegate this process to a library, but it is proposed to defer that
change to a future CL.
Bug: 141148175
Test: Built and flashed, checked directories were created.
Change-Id: I95a060b4f42241c91da25a779e61a8f85ca1914c
The HidlizationEquivalenceTest was used to make sure the same key is
computed by the scrypt algorithm regardless of whether the old
(<= KM2 HAL pre treble) or the new (>= KM3.0 treble) HAL was used.
Since the treble is now the default, and old HAL don't even exist on
new devices, we should call the migration a success and drop this test
altogether.
Test: Removed obsolete Code
Bug: 68197448
Change-Id: If10c79bafac4d0c8268675cbb8e1c4b46974aab5
The property is set to inform kernel to do a warm_reset on the next
reboot. This is useful to persist the logs to debug device boot
failures. After the slot has been marked as boot successful, we can drop
the warm_reset flag to avoid the performance overhead on the next
reboot.
Bug: 143489994
Test: check the property is set to 0 by vold
Change-Id: If7c922f40bcf9a6f7894af0a334ab23d88d40d17
