Date: Sat, 28 May 2016 11:24:55 -0600 From: Alan Somers <asomers@freebsd.org> To: Eric McCorkle <eric@metricspace.net> Cc: Allan Jude <allanjude@freebsd.org>, "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org>, "Kenneth D. Merry" <ken@freebsd.org> Subject: Re: EFI GELI support ready for testers Message-ID: <CAOtMX2h1XsG%2BMwpznXr2Hhiwe4-qi16J8%2BsGniOJsNQmOD%2BVVQ@mail.gmail.com> In-Reply-To: <B9C67D9B-6FF9-4F54-A1FD-EB17378B80D4@metricspace.net> References: <519CC1FC-84DF-4710-8E62-AF26D8AED2CF@metricspace.net> <20160528083656.GT38613@kib.kiev.ua> <d6b96a6c-4e92-35a5-e78b-cc674b6d2f25@freebsd.org> <B9C67D9B-6FF9-4F54-A1FD-EB17378B80D4@metricspace.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, May 28, 2016 at 9:23 AM, Eric McCorkle <eric@metricspace.net> wrote= : > >> On May 28, 2016, at 10:27, Allan Jude <allanjude@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/bo= ot >> >> 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 w= ork 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 beco= me somewhat disorganized. There seem to be two codebases (crypto and opencr= ypto), and multiple differing implementations for some ciphers. I ran into= this when trying to figure out how to add Camellia support. There's a usa= ble interface for AES CBC/XTS, but not Camellia CBC. There are also some i= nsecure ciphers (DES, RC4, etc) in there, some more modern ciphers (like ch= acha20) 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, an= d 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 dis= cussion. > >> >> 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 stro= ngly 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOtMX2h1XsG%2BMwpznXr2Hhiwe4-qi16J8%2BsGniOJsNQmOD%2BVVQ>