From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 27 00:04:01 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 57E759E1 for ; Fri, 27 Mar 2015 00:04:01 +0000 (UTC) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "anubis.delphij.net", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3B720FA1 for ; Fri, 27 Mar 2015 00:04:01 +0000 (UTC) Received: from zeta.ixsystems.com (unknown [12.229.62.2]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by anubis.delphij.net (Postfix) with ESMTPSA id EBF70E1BF; Thu, 26 Mar 2015 17:04:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1427414641; x=1427429041; bh=N4KIZt8vHQLLHOhC30bDNsYqpJKL3GjvyErTdR19nzY=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=m9/d4pqmxM+heNHQ8fd8726MCSWxu2R/FMCgFSzvog3PpKeAvi76Mn1AqpD9gKRv0 FSIWEzBVJ0xV6azLEMbF5LkulBUDrHh9UFsnjEnEoDI7+DNeMm6Yl9svA9UicHJlmZ yljzYiZXVRhy9A/ijN2UH9k0I0fZBcvgkgNuHYAw= Message-ID: <55149E70.30608@delphij.net> Date: Thu, 26 Mar 2015 17:04:00 -0700 From: Xin Li Reply-To: d@delphij.net Organization: The FreeBSD Project MIME-Version: 1.0 To: John-Mark Gurney , Pedro Arthur Subject: Re: GELI support on /boot folder References: <20150319013231.GR51048@funkthat.com> In-Reply-To: <20150319013231.GR51048@funkthat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: "" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2015 00:04:01 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 03/18/15 18:32, John-Mark Gurney wrote: > If we go thise route, I'd ask why we don't put loader into the > gptboot instead of using the existing shim to load loader... Then > the project would be to add GELI decryption to loader which could > then be used w/ MBR in the limited sense of loading kernel and > modules, though boot/loader would still have to be on an > unencrypted partition... > > I hope others who know the boot process better will inform us why > this is a good or bad idea... If we make changes to loader more often, it could be a bad idea because merging both parties would make it harder for those who develop loader changes. Additionally, it may be desirable to keep different copies of loaders in different "boot environment" datasets, it's more convenient for debugging: let's say one developer decided to make some changes to ZFS support of loader, and that's installed to a new boot environment, then they can try it out without making a usable boot disk at hand before hand. Once the zfsloader is proven to be working (we still have zfsloader.old or a different boot environment available), we would have much more confident that the system will boot after a gptzfsboot update because they share the same code. Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.1.2 (FreeBSD) iQIcBAEBCgAGBQJVFJ5rAAoJEJW2GBstM+ns2o8P/jdBS5VfnD2N+sKXyE7d7cmE nHzJVLA1TgkH7EdEwyzxpi/wv6LDmnsXDKAeS2iYU9T5v888XWpltJYo6Iq43h7j 5m7Y+BlMaLUlZl+IbmI07z8qrc4eYjsDKfzRiDuVTXMuW6AY5yfi+Ainmi0TbpyY KmQF5Xk/iQMUaK2S6Br3dckPnffxbaABaUUOLDwEVGwlorjsjw6pM2ckHWoSxzV6 ITE5mwhuAhE3JL/YUS0zhXD4y6ya62V4WOUbxQvivw0NHoqZ0RZhSistC5bPP5+Z JiNMVJx7NIrBYTXOpuUztpCs05QS88NF+AnMo2jtwZ78DRQFAvZAlKIV5+wAF2ZO pSTRFVir+MXM9mS4sLtg/0CViQ5V7VMPXeXP/9fHErWrSrGcM3sa4cUxI4/vfIeh cfu2MEV6+7G0anxu4x4El8epGOrK0r+oOyF2/LiiZ5fvsGLisTD8JgJvHk3g2Dh2 62ud004lTaq/ZamlLDq4gjO013MoVDVdLltfE526Fl2nL1y+loHSEnV3xflkFbfO INevkg39Oo2/Nl7d0vkJJwp3p53jhmQHKC7XBYZ4Taz5GWjJws9MUCZlD7IzlpfR ZS7Eomcu9S1bQdVxJX4kdaJEyWpmHrvLc5gye7wTM1E3evRjTinoNLDhIk2amUwb Y5kuXgSGxaJhqpjxaDal =5WOr -----END PGP SIGNATURE-----