I've given this a lot of thought. For what it's worth, if it were my
decision, I would first put your time into making a small change to the
installer to get the "encryption on" case perfect, rather than the
proposal in this bug.
The installer currently has:
O Erase disk an install Ubuntu
Warning: ...
[] Encrypt the new Ubuntu installation for security
You will choose a security key in the next step.
[] Use LVM with the new Ubuntu installation
This will set up Logical Volume Management. It allows taking
snapshots and easier partition resizing.
O EXPERIMENTAL: Erase disk and use ZFS
Warning: This will delete all your files on all operating systems.
This is experimental and may cause data loss. Do not use on
production systems.
O Something else
...
I would move the ZFS option to be a peer of / alternative to LVM
instead:
O Erase disk and install Ubuntu
Warning: ...
[] Encrypt the new Ubuntu installation for security
You will choose a security key in the next step.
Volume Managment:
O None (Fixed Partitions)
O Logical Volume Manager (LVM)
LVM allows taking snapshots and easier partition resizing.
O EXPERIMENTAL: ZFS
ZFS allows taking snapshots and dynamically shares space between
filesystems.
Warning: This is experimental and may cause data loss. Do not use
on production systems.
O Something else
...
This is a very straightforward UI change. The only new combination
introduced with this UI is encryption on + ZFS, which is what we want.
In that scenario, run the same passphrase prompting screen that is used
now for LUKS. Then pass the passphrase to `zpool create` (and use
encryption=aes-256-gcm for the reasons already discussed).
If the "always enable encryption" feature is to future-proof for people
who would otherwise choose "no encryption", that's worth considering,
but if it's an alternative to prompting them in the installer, I'm
personally opposed.
However, we do need to consider why they're turning off encryption. Are
they saying, "I don't want encryption ever (e.g. because of the
performance penalty)." or "I don't care about encryption right now." If
you always enable encryption, you are forcing encryption on them, which
has real performance impacts on older hardware. For example, I just
yesterday upgraded my personal server to use ZFS encryption, but made a
media dataset that is unencrypted. Sustained writes to the media dataset
are _at least_ twice as fast. With encryption, I was CPU bound. With it
off, I was not, so I suspect I could have written even faster. This
system is older and does not have AES-NI.
You mentioned spinning disks. Perhaps I misunderstood, but I don't know
why you'd be asking about spinning disks in particular. They are slower
than SSDs, so encryption is less likely to be a concern there, not more.
My server scenario involved spinning disks.
If the old wrapped master key were overwritten when changed _and_ the
system has AES-NI instructions, then I think it would be reasonable to
make "no encryption" turn on encryption anyway with a fixed passphrase.
This would achieve the goal of allowing encryption to be enabled later.
But I think that is second in priority to handling the "encryption on"
case.
--
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
