boot1-compatible GELI and GPT code?

[Eric McCorkle]

> On Mar 20, 2016, at 15:10, Eric McCorkle <eric at metricspace.net> wrote:
> 
> The only safe option to me seems to be either injecting the keys straight into 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 injection method.

Actually, I changed my mind.  The sanest way to support both HSMs and non-HSM methods all the way through the boot process, I think, would be to have modules that box up all of the asking for keys, storing them, and providing access/crypto functionality.  In EFI land, this would take the form of a module (COFF), probably stored on the efi partition and loaded by boot and subsequently 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 you get the keys out of it.

You could handle the non-HSM case by having an ELF image wrapped *inside* the COFF (EFI) image, where the COFF code ends up storing the keys in to the ELF image when it obtains them.  Then when loading the kernel modules, you copy 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 support.