Date: Sun, 20 Mar 2016 16:11:04 -0400 From: Eric McCorkle <eric@metricspace.net> To: Allan Jude <allanjude@freebsd.org> Cc: freebsd-hackers@freebsd.org Subject: Re: boot1-compatible GELI and GPT code? Message-ID: <2216F82C-A7FA-40DD-B2DF-9808DAA0BC77@metricspace.net> In-Reply-To: <CCE83F63-4CDA-47EA-9D5F-3BDDA752072A@metricspace.net> References: <8F22A0E2-45A3-463B-8CAC-16BEC8DA8883@metricspace.net> <1458497121.68920.83.camel@freebsd.org> <56EEEFBF.1000203@freebsd.org> <CCE83F63-4CDA-47EA-9D5F-3BDDA752072A@metricspace.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Mar 20, 2016, at 15:10, Eric McCorkle <eric@metricspace.net> 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.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2216F82C-A7FA-40DD-B2DF-9808DAA0BC77>