Date: Sun, 20 Mar 2016 12:05:21 -0600 From: Ian Lepore <ian@freebsd.org> To: Eric McCorkle <eric@metricspace.net>, "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Subject: Re: boot1-compatible GELI and GPT code? Message-ID: <1458497121.68920.83.camel@freebsd.org> In-Reply-To: <8F22A0E2-45A3-463B-8CAC-16BEC8DA8883@metricspace.net> References: <8F22A0E2-45A3-463B-8CAC-16BEC8DA8883@metricspace.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 2016-03-20 at 13:13 -0400, Eric McCorkle wrote: > Hello everyone, > > I'm working (among other things) on expanding the capabilities of the > EFI boot block to be able to load GELI-encrypted partitions, which > may contain a GPT partition table, in order to support full-disk > encryption. > > I'm wondering, is there any code for reading either of these formats > that could be used in boot1 hiding out anywhere? It'd be best to > avoid rewriting this stuff if possible. > > Also, I haven't investigated the capabilities of loader with regard > to GELI yet beyond cursory inspection. Most importantly, I need to > know if loader can handle GPTs and other partition formats inside a > GELI, or just single filesystems. > > As an additional note, it'd be best if there was a method for having > boot1 pass the key(s) along to loader and ultimately the kernel, so > the users don't have to input their keys 3 times. I'm open to > suggestions as to how to do this. My initial thought is to create > some kind of variable in both loader and kernel, then use the elf > data to locate it and directly inject the data prior to booting. The > rationale is to avoid mechanisms like arguments that could > potentially reveal the keys. GELI keys are currently passed from loader(8) to the kernel as environment variables. I was semi-horrified when I stumbled across that -- not the knee-jerk-reaction you'd expect from a security -obsessed person (because I'm soooo not one of those), but rather because it means that the memory passed from loader to the kernel containing the initial env vars must be writable, so that the geli key stuff can be zeroed after it's acccessed. That prevents making the pointer to that memory const everywhere, as it should be. It seems to me that a more correct way to pass the information may be as an opaque data blob, roughly the same way kernel modules and other loaded data gets passed from loader to the kernel. That might facilitate obscuring the info in some way as well. That doesn't really answer your question of how to pass it from boot1 to loader(8), though. There really isn't a lot of leeway there, you pretty much have to put it in memory somewhere (likely into an arch -specific bootinfo struct), and pass a pointer to it in a register when jumping to the loader(8) entry point. (Remember that all of this stuff applies to multiple platforms, not just x86, so it can't just be dropped into some well-known location in memory or anything like that.) -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1458497121.68920.83.camel>