Open marmarek opened 9 years ago
Not instantaneously, no:
[root@roxanne ~]# zfs create roxanne/unencrypted
[root@roxanne ~]# zfs snapshot roxanne/unencrypted@blah
[root@roxanne ~]# zfs clone -o encryption=on -o keyformat=passphrase roxanne/unencrypted@blah roxanne/encrypted
cannot create 'roxanne/encrypted': 'encryption' is readonly
The workaround is to use send and receive. You can send from an unencrypted snapshot to an encrypted dataset. But that is not instantaneous — it may take a while:
[root@roxanne ~]# zfs destroy roxanne/encrypted
[root@roxanne ~]# zfs send roxanne/unencrypted@blah | zfs receive -F -o encryption=on -o keyformat=passphrase -o keylocation=file:///etc/passwd roxanne/encrypted
[root@roxanne ~]# zfs get encryption roxanne/encrypted
NAME PROPERTY VALUE SOURCE
roxanne/encrypted encryption aes-256-gcm -
That performance hit may prove acceptable for a dvm private volume upon dvm instantiation, but I'm not sure it would be acceptable for the root volume of the dvm — that tends to be many gigabytes of data that needs rewriting from unencrypted into encrypted form.
zfs change-key
is not an option (hypothetically if we were cloning from an existing encrypted dataset to a disposable dataset, to make thing go faster) because changing the password does not change the master key (as per https://openzfs.github.io/openzfs-docs/man/master/8/zfs-change-key.8.html ).
I think what we want is simply that all writes to the dvm's disks are persisted with an ephemeral encryption key, and we use the underlying storage for reads, in a sort of overlay fashion. Smells like device-mapper all over again.
Reported by joanna on 25 Sep 2014 20:26 UTC Currently volatile.img is being backed up on the fs. See: https://groups.google.com/forum/#!topic/qubes-devel/QwL5PjqPs-4/discussion
Migrated-From: https://wiki.qubes-os.org/ticket/904