From owner-freebsd-hackers@freebsd.org Sun Apr 3 00:04:34 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 DB40CB01AC9 for ; Sun, 3 Apr 2016 00:04:34 +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 BAB011AE8 for ; Sun, 3 Apr 2016 00:04:34 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [172.16.0.5] (unknown [172.16.0.5]) (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 C345B1E54 for ; Sun, 3 Apr 2016 00:04:33 +0000 (UTC) Subject: Boot crypto framework patch, need testers From: Eric McCorkle Content-Type: text/plain; charset=us-ascii X-Mailer: iPad Mail (13D15) Message-Id: Date: Sat, 2 Apr 2016 20:04:32 -0400 To: "freebsd-hackers@freebsd.org" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Apr 2016 00:04:35 -0000 Hello, I've put together the following patch as part of a larger body of work I'm p= ursuing: https://github.com/emc2/freebsd/tree/boot_crypto This isn't a big patch, but it's aiming to be a central hub for boot-time cr= ypto, so it needs due consideration. This patch basically pulls all the cry= pto bits out of the recent geliboot work and moves them into a separate modu= le, called "boot_crypto". This is supposed to be a behavior-neutral patch, s= o it should be possible to drop it in to existing systems and have it Just W= ork. I'm not aware of other areas in the boot ecosystem that use crypto, bu= t if there are, they should probably be moved onto this framework as well. After studying the kernel crypto framework, GELI, and others, I have elected= NOT to try to design an interface for asking for passwords securely, storin= g keys, and other functionality I had previously contemplated. The existing= frameworks just don't support that kind of thing. I'm ok with this being reviewed to go in as-is, or it can be done as part of= my (very nearly finished) GELI EFI work. Whatever the decision, though, th= is is probably the best point to test that it doesn't break the existing gel= iboot functionality. The rationale for doing this code reorganization follows: * It helps avoid duplication and extra work for things like the EFI work * It makes it easier to add support for more ciphers (camellia and blowfish a= re unsupported in the current boot GELI implementation, for example, and act= ivity in the crypto world suggests new ciphers/modes will be arriving) * It lowers the overhead of implementing other crypto-based functionality at= boot time (gbde, ZFS encryption, secure boot, etc) * Boot crypto functionality has different enough needs (simplicity, small co= de size, etc) to warrant a boot-specific interface. * It's much easier to install an interface like this one when there are few c= onsumers than to rip out 5-6 random ad-hoc crypto implementations at some po= int in the future. *Especially* in a boot loader. Please review, test, and provide feedback. Thanks, Eric=