Thanks Richard for digging in, the performance comparison and the valuable upstream feedback and pointers. Good catch about retrieving the master key written in old blocks with the previous (fix) passphrase even if changed later on. It seems that trimming could help. Do you think that we should base on work going that direction (overwriting old keys) and keep the current approach?
On a more general side, the approach seems to be forward-compatible with per user dataset encryption (zfs change-key <dataset>), which creates a new encryption root. Steve: * the only comment I have on the ubiquity part of the equation is based on Richard's feedback. Otherwise, looks good to me. I think we should wait on the above feedback before taking a finale decision on the approach though. * the zfs-linux initramfs POC looks good (not tested though, currently travelling, but I didn't spot any issues). It should be easily pluggable later on once the user set it to "prompt" with their own passphrase and use the plymouth prompt codepath. (Not tested yet either). Just a nitpick: Colin asked for our patches in zfs-linux to be numbered (hence the 4XXX- namespace), as the debian ones. It seems that it's not reliably the case since the 0.8.2 merge with debian, so need double checking (order seems as well messy after this merge right now). Anyway, we need to wait on the kernel patches first. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to zfs-linux in Ubuntu. https://bugs.launchpad.net/bugs/1857398 Title: ubiquity should support encryption by default with zfsroot, with users able to opt in to running change-key after install Status in ubiquity package in Ubuntu: New Status in zfs-linux package in Ubuntu: New Bug description: zfs supports built-in encryption support, but the decision of whether a pool is encrypted or not must be made at pool creation time; it is possible to add encrypted datasets on top of an unencrypted pool but it is not possible to do an online change of a dataset (or a whole pool) to toggle encryption. We should therefore always install with encryption enabled on zfs systems, with a non-secret key by default, and allow the user to use 'zfs change-key -o keylocation=prompt' after install to take ownership of the encryption and upgrade the security. This is also the simplest way to allow users to avoid having to choose between the security of full-disk encryption, and the advanced filesystem features of zfs since it requires no additional UX work in ubiquity. We should make sure that https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1857040 is fixed first in the kernel so that enabling zfs encryption does not impose an unreasonable performance penalty. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1857398/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
