From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 27 18:09:53 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 513AE93E for ; Fri, 27 Mar 2015 18:09:53 +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 3143ED63 for ; Fri, 27 Mar 2015 18:09:53 +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 A6580114D3; Fri, 27 Mar 2015 11:09:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1427479792; x=1427494192; bh=qOVO0Vx6VQ2LZJw2z3eULsNEV9GxdhggJn2St6xXSN8=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=EKzOSAnCFwTkjI0qyMN553myLUOjeOY/umn69ggTIerpPsFIWc2aBlSxJhEaQY28U 9eHpM3Rr3Ztmq6BwvYP2JMOWwRn+YClc8PIXJwheAkoU6VdgtihN56E+PGNJiAfFc4 hJ9zZ0kbAsC8lDDwLG1NDIQGyQnF/6Uo53tS2dms= Message-ID: <55159CF0.9060700@delphij.net> Date: Fri, 27 Mar 2015 11:09:52 -0700 From: Xin Li Reply-To: d@delphij.net Organization: The FreeBSD Project MIME-Version: 1.0 To: Pedro Arthur , d@delphij.net Subject: Re: GELI support on /boot folder References: <20150319013231.GR51048@funkthat.com> <55149E70.30608@delphij.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: "" , John-Mark Gurney 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 18:09:53 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 03/26/15 19:56, Pedro Arthur wrote: > I think that encrypting the boot folder will protect the boot > configurations, kernel and kernel modules from being changed. I see... Have you considered other approaches for this goal, for instance verifying signature? (But to make it useful, we still need something in the BIOS/EFI to enforce the integrity of the boot code itself). >> 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. >> >> I agree with you, but the boot2 has already reached its size >> limit.For > example if you try to compile the boot2 with clang < 3.5 (>=3.5 > uses the enable-gvn flag) you will get an error saying boot2 > exceeded its max size by ~20 bytes. I can't see other way to do it > without merging. Hmm I don't quite follow -- we were discussing about whether to merge gpt[zfs]boot with [zfs]loader, right? (I don't have strong opinion on whether we merge or not merge the two, just would like to point out the pro/cons). 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) iQIcBAEBCgAGBQJVFZztAAoJEJW2GBstM+nsBLUP/RuzlcrJ6+WW3h5vUF0gNwb+ zEv/WAPtiH6pZIgcUmUkL2F4icKEiEknoTgPhObpgARGPx4xrm7pYHZ4Zsule/MS KYE3Sys8eLwIONHSBl1sHJ3WV8K/Jv+buwRDWXsmwtjH8e7C5yxrmuytp4XJ4Lxp pRIqNJmfdPJOI1bNMJCI4sPNHo/1pnxQGNTN2vxJAdjSzgh9FvIiH00CyHm+r23z ZCQn1aAGded2Rnv4boG0EPklKQA38GG8kHdtQVaLySDZL13BvHFbF0P09b/1m0I7 TXypho3xgHEI2vVDiLPPIgFdnFm95AJ2ibVu5UP3g+4iqiGMSwtq7XYZRnDIGVJ5 MxZdgTgf1c7tvmf8SoQLFnfDVi8RfVzh+CpmbWr7+KotuW3BMfOgd20V2z/ItDhF 9ptZDPUILrqEUL127HwSMENX8mwLmMDo14lPzRtan7YfoIgNMgAh0B0ZwP5Ow0yO txsJ8/YQYgcCOP3sQinyu+OV3OD91qlK0OBIePrqX8eP5jI1paflXElikWhEYjvi pNO2c+HenFm09OGGaW5PrHvIk4fjknkpq0ndwS2a8dSQS2zFaEvfzvKvoCr2x7Lh KtTzdGrORXdYelHndeMg8dh9LXDWEQgNdWBNP+xKnL23xaXcVWo8qgWpLM4RIc72 uGDJqiUysU9rDEf3oq7z =H1bs -----END PGP SIGNATURE-----