From owner-freebsd-hackers@freebsd.org Sun Mar 20 18:05:30 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 53ADAAD7DCB for ; Sun, 20 Mar 2016 18:05:30 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3A8A96B9 for ; Sun, 20 Mar 2016 18:05:29 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 56533f21-eec6-11e5-9036-c33267960ba8 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.34.117.227 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.34.117.227]) by outbound2.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Sun, 20 Mar 2016 18:05:32 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.14.9) with ESMTP id u2KI5LDG006313; Sun, 20 Mar 2016 12:05:21 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1458497121.68920.83.camel@freebsd.org> Subject: Re: boot1-compatible GELI and GPT code? From: Ian Lepore To: Eric McCorkle , "freebsd-hackers@freebsd.org" Date: Sun, 20 Mar 2016 12:05:21 -0600 In-Reply-To: <8F22A0E2-45A3-463B-8CAC-16BEC8DA8883@metricspace.net> References: <8F22A0E2-45A3-463B-8CAC-16BEC8DA8883@metricspace.net> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.16.5 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit 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 18:05:30 -0000 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