Very long encryption time on large disks

[bencorrado]

When provisioning a new device and dd'ing from /dev/${CRYPTO_HDD} to /dev/mapper/${CRYPTO_HDD} it can take many hours when the disk is large (8+ hours with a large NVMe).

I have been considering changing installer to put a copy of the data to a tmp secondary partition. You would then boot the GyroidOS and the init script would create the CRYPTO_HDD partition, dm_crypt it, create an ext4 on it, then copy the files from the tmp partition and delete the tmp parition. There could then be a background task that exercises all the blocks on the /dev/mapper/${CRYPTO_HDD} to make sure it has reasonable randomness.

Potentially the tmp partition could stay as a recovery partition, but I have not come up with a good way to secure it yet, so probably just delete it.

Line that takes forever:
https://github.com/gyroidos/meta-trustx/blob/7adbca37282396d7414ae45955e39300ead9225d/recipes-initscripts/cml-boot/files/cml-boot-script.stub#L106C1-L106C103

[quitschbo]

@bencorrado one thing is that the dd part is using 512 block size which is I think for ssds not the best size.
Maybe if we just increase it to 4096 this would be more efficient already.

@MPeisl just trying another Idea by using cat which determines buffer sizes internally more optimistic than the 512 bytes and also should scale on several cores. However, I do not know if the simple busybox-cat implementation would do this, too.

So I think to speed the current thing up a little we just could try those two simple steps first.

However, your Idea with the backround task seems reasonable. Maybe we just do not expand the filesystem to the whole disk in the installer but only a reasonable minimal size to hold the first containers. say 5 - 10GB. Do the oft on this and then let the cmld or tpm2d do the rest of the disk randomization during runtime as background task on the free space. When that is finshed we just expand the ext4fs on the /dev/mapper/${CRYPTO_HDD}.

[MPeisl]

@bencorrado, @quitschbo: Preliminary testing of #243 inside a VM suggests that cat is around 8-10x faster than the current dd approach.

[quitschbo]

Ok then I think we will take the cat approach for now.