From owner-freebsd-hackers@freebsd.org Sun Mar 27 23:34:39 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 B784EADFF47 for ; Sun, 27 Mar 2016 23:34:39 +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 97CEC14A7 for ; Sun, 27 Mar 2016 23:34:38 +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 D68A910CF for ; Sun, 27 Mar 2016 23:34:31 +0000 (UTC) Subject: EFI GELI boot update From: Eric McCorkle Content-Type: text/plain; charset=us-ascii X-Mailer: iPad Mail (13D15) Message-Id: Date: Sun, 27 Mar 2016 19:34:30 -0400 To: "freebsd-hackers@freebsd.org" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) 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, 27 Mar 2016 23:34:39 -0000 Just to give an update, as I know there were some others looking into GELI s= upport for EFI, I've made modifications to boot1 to support "provider" modul= es, which basically handle subpartitions. You can track my work on this her= e:=20 https://github.com/emc2/freebsd/tree/geli_efi I had considered using the EFI API more for this (creating device nodes, add= ing protocols, and binding device paths), but decided not to in order to kee= p loader working with a GRUB setup. As for actual GELI support, here's the roadmap I'm considering: * Abstract the use of struct dsk out of the core data structures * Abstract the crytpto, password-asking, and key material storage out of the= GELI code into some kind of boot crypto framework. Ideally, this would be s= modules-type framework with BIOS and EFI software crypto modules provided. = Hardware crypto could be supported in the future by adding more modules. * (Possibly) come up with a better way to transfer key material to loader an= d the kernel * Mirror the functionality of the provider modules in loader I welcome any suggestions on any of this.=