EFI GELI support ready for testers

[Alan Somers]

On Sat, May 28, 2016 at 9:23 AM, Eric McCorkle <eric at metricspace.net> wrote:
>
>> 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.

The problem with opencrypto is that it was written when crypto
accelerators lived on PCI cards and were treated as shared resources.
That's why userland programs wishing to use opencrypto have to send
all of their data into the kernel.  It's a very inefficient way of
using CPU-resident accelerators like AESNI and Padlock.  For clients
within the kernel, it's not so bad.  It adds a few extra stack frames
and a lot of code but there are no additional data copies.  crypto(3),
OTOH, is part of OpenSSL.  AFAIK it doesn't have the data copies
problem, but it's still quite complicated.  ken@ once tried to build
OpenSSL into the kernel but gave up because it has too many
dependencies.

So neither of these libraries is suitable for use in both kernel and
userland.  I don't know of any that is (though I haven't looked).

-Alan