freebsd
geom/luks: LUKS v1 read-write support
This adds a new GEOM for LUKS (Linux Unified Key Support) disk encryption version 1.
We'd want to squash the followup commit (changing the debug level default) into the first commit. You can do that locally and push an update to this pull request, or it can be done by whoever merges this into the tree.
I apologize in advance that this will likely take some time to review (as would anything involving cryptography).
I would be interested in hearing a bit more about the background/context for this change, out of curiosity.
It's preferable to take some time when reviewing crypto.. In fact I'm delighted to come to BSD from Linux, but I've a bunch of Luks-encrypted old data that I may use. It was faster to write a Geom than copy these disks ! I will probably end to convert some to Geli, which I found more attracting.So I'll also try to port Luks version 2, but it needs a small JSON parser (quite done), and Blake2b, Argon2i algorithms..As I'm discovering Geom, a nice part of FreeBSD, there'll be probably things to change (tests in progress).
Roughly speaking, GELI = Linux dm-crypt (disk encryption, LUKS is the keystore) + Linux dm-verity (data integrity).
When I planned to use FreeBSD as my main OS, I had two questions: (1) is there a mean to access my Luks-encrypted data without doing a full decryption of the disks, and, (2) will I need to go back to Linux in case some software is not running under FreeBSD ? As an example, I do not know yet if the AMD-Xilinx FPGA tools are natively supported using the Linux compatibility layer.
In the first case, write support is not required. In the second, as well in the virtualization use case, write support is a nice mean to exchange encrypted data between Linux and FreeBSD.
I will do some code changes according to all remarks, but I decided for now to make a try about Luks v2 support, using the v1 code as base, as only the Luks header is different in v2, but more annoying to parse. Tests are also needed for the write part.
I sent the version 1 to get feedback and because the data I'm using daily is encrypted using Luks (currently, I'm running both Linux and FreeBSD).
Looks like the review comments haven't been addressed, unless I'm missing something. Tagged this with 'changes required' until that happens. Also, using this a 'ping' to see if it's still relevant, or if it's gone in as a port, etc.
@n-p-soft This looks interesting... Do you plan on abandoning this for v2 support? Or is it still relevant with your plans? If it's going to be a while, I'd like to close this out, but invite you to reopen / create a new pull request when the time comes. What's up?
I'm going to close this as inactive, with an unclear path forward. If you implement v2 or feel that v1 has improved enough to include in FreeBSD, please open a new pull request. Thanks!