The apex data directories must be accessed by apexd in order for it to
perform snapshot and restore as part of the rollback process. As apexd
runs as root, this CL changes the apex data directories under misc_[ce|de]
to be owned by root.
Bug: 141148175
Test: Build and flash; check permissions are set correctly.
Change-Id: Icf2059cc9448364f834eef7892914a99883746a1
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
Now that we include libfscrypt in libfs_mgr via whole_static_libs we
should not reference it directly.
Bug: 143307095
Test: treehugger
Change-Id: I4cd138b50131ec8ce7835d9604c89c99cae53212
am: be4ff998ac -s ours
am skip reason: change_id I7191bd73d8621831c5802e02817f459f1da32754 with SHA1 a2c2182b65 is in history
Change-Id: If1bc31b59c868707ff2b4ee406bcad0fa9da25d3
am: 8a9454c35c -s ours
am skip reason: change_id I7191bd73d8621831c5802e02817f459f1da32754 with SHA1 a2c2182b65 is in history
Change-Id: I0e4e568d378d9412f2239f37ba2c475ad4f5f30b
A little bit more self-explanatory name that explicitly says that root
is also allowed.
Test: builds
Change-Id: Ice20ffcba2a0994c599dbebace252138ffd827de
Merged-In: Ice20ffcba2a0994c599dbebace252138ffd827de
