EFI GELI support ready for testers

[Eric McCorkle]

> On May 28, 2016, at 10:27, Allan Jude <allanjude at freebsd.org> wrote:
> 
> The final version of my geliboot took an extra effort to reuse the AES
> code from sys/crypto/rijndael and sys/opencrypto and GELI directly from
> sys/geom/eli to avoid maintaining a separate copy of that code in sys/boot
> 
> Hopefully the work I did to make sys/opencrypto and sys/geom/eli more
> reusable outside of the kernel will make it easier for Eric to do the
> same for the EFI version.

It did indeed make things easier, though I think there is potential for work to be done on the crypto framework.  It looks like the crypto framework has kind of accumulated code over time from different sources and has become somewhat disorganized. There seem to be two codebases (crypto and opencrypto), and multiple differing implementations for some ciphers.  I ran into this when trying to figure out how to add Camellia support.  There's a usable interface for AES CBC/XTS, but not Camellia CBC.  There are also some insecure ciphers (DES, RC4, etc) in there, some more modern ciphers (like chacha20) are missing, and it's possible to implement ciphers other than AES using AESNI/AVX instructions to achieve hardware acceleration.

It also ought to be simpler to share crypto code between kernel, boot, and userland, imo.  In theory, one could have a single library (with multiple compilations for different ABIs) that could be statically linked into the kernel and boot loaders, and also installed in to the base OS.

I'm not sure if there's any plans for crypto, but it might be worth a discussion.

> 
> The motivation for the EFI version is the same, ZFS boot environments,
> plus the obvious security advantages of having the kernel stored
> encrypted rather than not.
> 

The ability to have a single ZFS filesystem is indeed a motivator for the EFI work.  I forgot to mention it because my personal motivations are strongly focused on security and tamper-resistance.