GELI support on /boot folder

Pedro Arthur bygrandao at gmail.com
Sat Mar 28 01:32:34 UTC 2015


Disregard this boot2 comment, it has nothing to do with the gptboot

2015-03-27 15:09 GMT-03:00 Xin Li <delphij at delphij.net>:

> -----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 at 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-----
>


More information about the freebsd-hackers mailing list