Date: Thu, 26 Mar 2015 23:56:00 -0300 From: Pedro Arthur <bygrandao@gmail.com> To: 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: <CAKN1MR5ghmoNn30=mvXwf89LYd9HhTALGXziMrxMct62W48r-w@mail.gmail.com> In-Reply-To: <55149E70.30608@delphij.net> References: <CAKN1MR54TCWZa_wSLAe63fxVF6248yr_aKkg-T0WtxHzaiLkyw@mail.gmail.com> <20150319013231.GR51048@funkthat.com> <55149E70.30608@delphij.net>
next in thread | previous in thread | raw e-mail | index | archive | help
I think that encrypting the boot folder will protect the boot configurations, kernel and kernel modules from being changed. > 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAKN1MR5ghmoNn30=mvXwf89LYd9HhTALGXziMrxMct62W48r-w>