Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 27 Mar 2015 11:09:52 -0700
From:      Xin Li <delphij@delphij.net>
To:        Pedro Arthur <bygrandao@gmail.com>, d@delphij.net
Cc:        "<freebsd-hackers@freebsd.org>" <freebsd-hackers@freebsd.org>, John-Mark Gurney <jmg@funkthat.com>
Subject:   Re: GELI support on /boot folder
Message-ID:  <55159CF0.9060700@delphij.net>
In-Reply-To: <CAKN1MR5ghmoNn30=mvXwf89LYd9HhTALGXziMrxMct62W48r-w@mail.gmail.com>
References:  <CAKN1MR54TCWZa_wSLAe63fxVF6248yr_aKkg-T0WtxHzaiLkyw@mail.gmail.com> <20150319013231.GR51048@funkthat.com> <55149E70.30608@delphij.net> <CAKN1MR5ghmoNn30=mvXwf89LYd9HhTALGXziMrxMct62W48r-w@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
-----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 <delphij@delphij.net>    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-----



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?55159CF0.9060700>