From owner-freebsd-hackers@freebsd.org Sat May 28 15:23:42 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D0A2DB4E456 for ; Sat, 28 May 2016 15:23:42 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::107]) by mx1.freebsd.org (Postfix) with ESMTP id AE2D110CB; Sat, 28 May 2016 15:23:42 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [IPv6:2001:470:1f11:617:8fe:6a13:797b:e9c9] (unknown [IPv6:2001:470:1f11:617:8fe:6a13:797b:e9c9]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id 331611776; Sat, 28 May 2016 15:23:42 +0000 (UTC) References: <519CC1FC-84DF-4710-8E62-AF26D8AED2CF@metricspace.net> <20160528083656.GT38613@kib.kiev.ua> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Cc: freebsd-hackers@freebsd.org X-Mailer: iPad Mail (13D15) From: Eric McCorkle Subject: Re: EFI GELI support ready for testers Date: Sat, 28 May 2016 11:23:41 -0400 To: Allan Jude X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 May 2016 15:23:42 -0000 > On May 28, 2016, at 10:27, Allan Jude 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.=