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
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
Nothing defines CONFIG_HW_DISK_ENCRYPTION, so remove the unused code
that's conditional on it being defined.
Change-Id: Ie435e138686eb4eac47d9aa762ae06f1645a117f
Block groups with EXT4_BG_BLOCK_UNINIT still have backup superblocks
(and backup block group descriptors). Fix EncryptInPlace to encrypt
these backup superblocks rather than leave them unencrypted.
Previously leaving the backup superblocks unencrypted didn't cause any
problems, but due to system/core commit 72abd7b246f7 ("Try to recover
corrupted ext4 /data with backup superblock") it is causing problems.
Bug: 162479411
Bug: 161871210
Change-Id: Ic090bf4e88193b289b04c5254ddf661ef40b037e
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
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
We rename our 'buf' in the inner scope to avoid confusion with
the 'buf' in the outer scope which is used immediately after
exiting the inner scope.
Test: TreeHugger
Change-Id: I1c50546e86c680e963eedcbda26138f8b43e55e9
This will allow adding lots of verbose logs which can be enabled
only during local testing/debugging. Update the existing verbose
level logs to debug level since we want those to be logged by
default.
Test: manual
Change-Id: Ib05e2b6efa71308458d49affb6ed81d3975b28ab
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
