From owner-freebsd-hackers@freebsd.org Sat May 28 20:19:14 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 B56D8B4E347 for ; Sat, 28 May 2016 20:19:14 +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 8829B11B7; Sat, 28 May 2016 20:19:14 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [172.16.0.97] (unknown [172.16.0.97]) (using TLSv1.2 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 D4C3E17EB; Sat, 28 May 2016 20:19:13 +0000 (UTC) User-Agent: K-9 Mail for Android In-Reply-To: References: <519CC1FC-84DF-4710-8E62-AF26D8AED2CF@metricspace.net> <20160528083656.GT38613@kib.kiev.ua> MIME-Version: 1.0 Subject: Re: EFI GELI support ready for testers From: Eric McCorkle Date: Sat, 28 May 2016 16:19:12 -0400 To: Alan Somers CC: Allan Jude , "freebsd-hackers@freebsd.org" , "Kenneth D. Merry" Message-ID: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.22 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 20:19:14 -0000 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 wrote: >On Sat, May 28, 2016 at 9:23 AM, Eric McCorkle >wrote: >> >>> On May 28, 2016, at 10:27, Allan Jude 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.