4 ms·
>on disk encryption Given you could just run LUKS on top of (open)ZFS, it's probably the better security position to run an audited, established encryption pro
by technion 11y ago
>on disk encryption
Given you could just run LUKS on top of (open)ZFS, it's probably the better security position to run an audited, established encryption product, than to consider a layer thrown on top of ZFS a feature.
- belovedeagle 11y agoThere are major benefits to be had from moving the encryption layer on top of the volume management/storage EDAC layers which ZFS provides: in particular, it'd be nice to be able to scrub a locked dataset. I think (but haven't seen this firsthand) that Oracle's implementation offers that benefit.
- olavgg 11y agoYou can still scrub a dataset with GELI (https://www.freebsd.org/cgi/man.cgi?geli%288%29 https://www.freebsd.org/cgi/man.cgi?geli%288%29) GELI creates a virtual block device that works great with ZFS, you get it all, self-healing, checksumming etc.
- belovedeagle 11y agoIt looks like GELI goes below zfs just like dm-crypt. That doesn't allow you to scrub a locked dataset (one where the key is not in memory, possibly unknown). You could use zvols, of course, but that loses some (but not all) of the full-stack zfs benefits.
- olavgg 11y agoNo, you create virtual block devices that needs to be "unlocked" before you can start using ZFS. If you need to scrub the dataset, you need to unlock all the virtual block devices, start ZFS and then run the scrub command. The whole point is to run ZFS on top of virtual block devices which are encrypted with GELI and "unlocked".
- XorNot 11y agoThis is kind of a poor defence. ZFS built-in encryption would be a great feature, but since the source got leaked implementing it is a bit of a legal minefield.