From owner-freebsd-hackers@freebsd.org Sun Mar 20 20:11:07 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 C26B8AD753C for ; Sun, 20 Mar 2016 20:11:07 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (207-172-209-83.c3-0.arl-ubr1.sbo-arl.ma.static.cable.rcn.com [207.172.209.83]) by mx1.freebsd.org (Postfix) with ESMTP id 8F58EC96; Sun, 20 Mar 2016 20:11:07 +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 3979F13FD; Sun, 20 Mar 2016 20:11:05 +0000 (UTC) References: <8F22A0E2-45A3-463B-8CAC-16BEC8DA8883@metricspace.net> <1458497121.68920.83.camel@freebsd.org> <56EEEFBF.1000203@freebsd.org> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <2216F82C-A7FA-40DD-B2DF-9808DAA0BC77@metricspace.net> Cc: freebsd-hackers@freebsd.org X-Mailer: iPad Mail (13D15) From: Eric McCorkle Subject: Re: boot1-compatible GELI and GPT code? Date: Sun, 20 Mar 2016 16:11:04 -0400 To: Allan Jude 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, 20 Mar 2016 20:11:07 -0000 > On Mar 20, 2016, at 15:10, Eric McCorkle wrote: >=20 > The only safe option to me seems to be either injecting the keys straight i= nto the executable, or else synthesizing modules containing them and loading= them. Now, you'll need to also do this for loader, which is a COFF binary.= Both approaches have their merits, though I think I slightly prefer the in= jection method. Actually, I changed my mind. The sanest way to support both HSMs and non-HS= M methods all the way through the boot process, I think, would be to have mo= dules that box up all of the asking for keys, storing them, and providing ac= cess/crypto functionality. In EFI land, this would take the form of a modul= e (COFF), probably stored on the efi partition and loaded by boot and subseq= uently used provided by loader. In kernel land, this would be kernel module= . In the non-HSM case, you could probably jettison the kernel module after y= ou get the keys out of it. You could handle the non-HSM case by having an ELF image wrapped *inside* th= e COFF (EFI) image, where the COFF code ends up storing the keys in to the E= LF image when it obtains them. Then when loading the kernel modules, you co= py the elf image out and load it, then zero out the original image. This interface probably ought to be informed by the kernel crypto framework.= Also, I'm admittedly lacking in knowledge about FreeBSD hardware crypto su= pport.=