From owner-freebsd-hackers@freebsd.org Sun Mar 20 19:10:58 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 25012AD7A99 for ; Sun, 20 Mar 2016 19:10:58 +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 F3D1ED90; Sun, 20 Mar 2016 19:10:57 +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 A9AE913D9; Sun, 20 Mar 2016 19:10:56 +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: <56EEEFBF.1000203@freebsd.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: 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 15:10:55 -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 19:10:58 -0000 In EFI, you don't have the bootinfo struct, you just have command-line style= args going from boot to loader. Right now, the efi loader doesn't even loo= k at the args. Some thoughts: * The ideal solution (if you trust HSMs and have one at all) would be to loa= d the keys into an HSM in boot, and rely on it from there. That's a lot of h= ardware support in boot, though. * There is some incentive to avoid args/env variables. There's a very real r= isk of your keys getting leaked by debugging/logging messages. Also, at lea= st in the efi boot to loader transition, I wouldn't put it past the likes of= Lenovo to record all ExecImage activity, which would slurp the keys if that= method was used. Also, it'd be big change to the efi loader to add args (an= d a potential vuln to parse them) * With the variable injection method I proposed as well as with a method of s= ynthesizing a loadable module in memory, an attacker capable of getting the k= eys would have to be able to access kernel memory. The only safe option to me seems to be either injecting the keys straight in= to the executable, or else synthesizing modules containing them and loading t= hem. Now, you'll need to also do this for loader, which is a COFF binary. B= oth approaches have their merits, though I think I slightly prefer the injec= tion method. > On Mar 20, 2016, at 14:45, Allan Jude wrote: >=20 >> On 2016-03-20 14:05, Ian Lepore wrote: >>> On Sun, 2016-03-20 at 13:13 -0400, Eric McCorkle wrote: >>> Hello everyone, >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> 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. >>=20 >> 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. >>=20 >> 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. >>=20 >> 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.) >=20 > This is how I did it in my recent work. Added an additional field to the > 'extended boot info' struct, to pass the data from boot2 to the loader. > My work only targeted i386/amd64. >=20 >> -- Ian >>=20 >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org= " >=20 >=20 > --=20 > Allan Jude >=20