EFI GELI support ready for testers

[Eric McCorkle]

I see. They're part device interface, part software crypto implementation.  I guess the question is, does the software crypto *have* to live there, or could it be in a separate library? 

I'm less inclined to trust OpenSSL completely these days, and it certainly is a beast to integrate into anything.

Some compelling alternatives have emerged in the wake of heartbleed.  Off the cuff, I'd say NaCl is a good option: it's public domain and it's got some big names in crypto attached to it.  But I don't know enough to say for sure if it could do what I proposed. 

On May 28, 2016 1:24:55 PM EDT, Alan Somers <asomers at freebsd.org> wrote:
>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

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.