Crypto block device is needed for device mapper based data
encryption for any partition. Close the device file pointer
when data packet is encrypted.
CRs-Fixed: 2417032
Change-Id: I0fa7c4829665b8a505a5abf598bb54b7835f71e0
Metadata encryption essentially encrypts userdata filesystem metadata
using Inline crypto engine based block disk encryption concept. New
Inline crypto engine based block disk encryption design do not create
crypto block device. When metadata encryption was enabled it needed
crypto block device to encrypt the metadata. So if metadata partition
is mounted on device block disk encryption did not work. Fix this by
checking whether crypto block device was created or not to switch
between two data encryption calls.
CRs-Fixed: 2389467
Change-Id: Ic46244ab08f31e71865636f1a2470f914ca88547
Crypto block device is not required for ICE based
HW FDE solution. This introduces additional delay
and is redundant since data is encrypted inline.
CRs-Fixed: 2210986
Change-Id: I67c044c35e92d2aa9413bc3448b6193f6b6a01d7
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
Merged-In: Ic090bf4e88193b289b04c5254ddf661ef40b037e
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
Neeraj Soni
AnilKumar Chimata
Will Shiu
Denis Hsu
Paul Lawrence
Greg Kaiser
Sudheer Shanka
Paul Crowley
Elliott Hughes