Date: Sat, 28 May 2016 11:23:41 -0400 From: Eric McCorkle <eric@metricspace.net> To: Allan Jude <allanjude@freebsd.org> Cc: freebsd-hackers@freebsd.org Subject: Re: EFI GELI support ready for testers Message-ID: <B9C67D9B-6FF9-4F54-A1FD-EB17378B80D4@metricspace.net> In-Reply-To: <d6b96a6c-4e92-35a5-e78b-cc674b6d2f25@freebsd.org> References: <519CC1FC-84DF-4710-8E62-AF26D8AED2CF@metricspace.net> <20160528083656.GT38613@kib.kiev.ua> <d6b96a6c-4e92-35a5-e78b-cc674b6d2f25@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> On May 28, 2016, at 10:27, Allan Jude <allanjude@freebsd.org> wrote: >=20 > 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= >=20 > 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 so= mewhat disorganized. There seem to be two codebases (crypto and opencrypto),= and multiple differing implementations for some ciphers. I ran into this w= hen trying to figure out how to add Camellia support. There's a usable inte= rface for AES CBC/XTS, but not Camellia CBC. There are also some insecure c= iphers (DES, RC4, etc) in there, some more modern ciphers (like chacha20) ar= e 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 u= serland, imo. In theory, one could have a single library (with multiple com= pilations for different ABIs) that could be statically linked into the kerne= l 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 discus= sion. >=20 > 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. >=20 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 f= ocused on security and tamper-resistance.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B9C67D9B-6FF9-4F54-A1FD-EB17378B80D4>