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 Ubuntu
Bugs, which is subscribed to 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
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1857398/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
