From owner-freebsd-hackers@freebsd.org Sun Mar 20 18:45:21 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 20F88AD747B for ; Sun, 20 Mar 2016 18:45:21 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from mx1.scaleengine.net (mx1.scaleengine.net [209.51.186.6]) by mx1.freebsd.org (Postfix) with ESMTP id 003551B89 for ; Sun, 20 Mar 2016 18:45:20 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from [10.1.1.2] (unknown [10.1.1.2]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 5E404D6CC for ; Sun, 20 Mar 2016 18:45:20 +0000 (UTC) Subject: Re: boot1-compatible GELI and GPT code? To: freebsd-hackers@freebsd.org References: <8F22A0E2-45A3-463B-8CAC-16BEC8DA8883@metricspace.net> <1458497121.68920.83.camel@freebsd.org> From: Allan Jude Message-ID: <56EEEFBF.1000203@freebsd.org> Date: Sun, 20 Mar 2016 14:45:19 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <1458497121.68920.83.camel@freebsd.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="511EPBogwCeR35nhtG0qaQaMjUGhGJVVC" 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:45:21 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --511EPBogwCeR35nhtG0qaQaMjUGhGJVVC Content-Type: multipart/mixed; boundary="7NAhgG6OaLKWfRdt0PfnINkfcKSGapUhG" From: Allan Jude To: freebsd-hackers@freebsd.org Message-ID: <56EEEFBF.1000203@freebsd.org> Subject: Re: boot1-compatible GELI and GPT code? References: <8F22A0E2-45A3-463B-8CAC-16BEC8DA8883@metricspace.net> <1458497121.68920.83.camel@freebsd.org> In-Reply-To: <1458497121.68920.83.camel@freebsd.org> --7NAhgG6OaLKWfRdt0PfnINkfcKSGapUhG Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2016-03-20 14:05, Ian Lepore wrote: > 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. >=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. > -- 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.o= rg" >=20 --=20 Allan Jude --7NAhgG6OaLKWfRdt0PfnINkfcKSGapUhG-- --511EPBogwCeR35nhtG0qaQaMjUGhGJVVC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJW7u+/AAoJEBmVNT4SmAt+YE4QAJTRyaGZdZNCkKc+rcKkO89c 8sqTr2vtTRvblxplC7ceRQn7E8Da8cPvSIBBtxftqUV7feCimvz3XyT/JD1uGh+h nElZknMkpW7NGxbDnLHIIs6MttpwQHWzyP/ToEEwtz0AR0mGF36KQHSeYUM+rN4c i+FTXt+avZH5PRbu8bpTZZfq0c7Csve0WMtQ5l2N+F10GNzTxR+ZfarOalAJ+SXk zMINhjMxyWGNNYe6HLj8viPopp9+UlHYlJfKpWvihX5xP4bn2prX4be3JOn/w438 2zPkElDcrcRdJsIPvk+hdbrpLOfmOcHpMeOY+1kmHFwUtaOgbTxwgjIMB8mPraWD BMGZwQSoUlbRTG27yWlw69FPr9P5+sQ9RsaTAl6A7YXXE+1053ghEPs16fd+avIJ 6O+vIrw4JUNBT1NoQkOsFtj8ikLNn3yGxeON8sWr923vwXtej4ejCrW9z1Yj+ghr mXfJPsXrBtDDaCohjPFdeuRtydoKwU2n38X/n6bJggP/y3w1FvgMbKGvK4Zpfp0J N6qP7IGDiD6+UMUl6iOab0SIuhtedN3vuiCr0XeIDeN6mkqa1S2jMPOV+pNZas2G Gjt8vQWkJKYmrS0Pix5ZOclEaq3VVZLY8iIcGiltG9NSRQLQmUsgCgCoCu59rn6h oDSujFCsJ/jtyrGGIZKf =jmi6 -----END PGP SIGNATURE----- --511EPBogwCeR35nhtG0qaQaMjUGhGJVVC--