Date: Mon, 23 Mar 2015 17:46:20 -0300 From: Pedro Arthur <bygrandao@gmail.com> To: John-Mark Gurney <jmg@funkthat.com> Cc: "<freebsd-hackers@freebsd.org>" <freebsd-hackers@freebsd.org> Subject: Re: GELI support on /boot folder Message-ID: <CAKN1MR4D-hdX0Koy45LSg_zo-uvLi=njyPwSfYcVBYi5FT_C=w@mail.gmail.com> In-Reply-To: <20150319013231.GR51048@funkthat.com> References: <CAKN1MR54TCWZa_wSLAe63fxVF6248yr_aKkg-T0WtxHzaiLkyw@mail.gmail.com> <20150319013231.GR51048@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Based on your idea the project could be merge the GPT boot stages into a single program with support for GELI and instead of having a binary for zfs and other for ufs we could have the boot program with support for both file systems so that we can choose to boot from any partition in the GPT being zfs or ufs. What I want to know is if it is a good idea or merging these boot stages has any drawback or infringes any design choices? 2015-03-18 22:32 GMT-03:00 John-Mark Gurney <jmg@funkthat.com>: > Pedro Arthur wrote this message on Wed, Mar 18, 2015 at 15:50 -0300: > > I was discussing with Kris Moore about adding support for GELI in > > bootloader as a GSoC project, > > thus the /boot folder could be encrypted. > > However the stage 2 boot program has a limit size of ~8 Kb which is > almost > > reached in the default > > HEAD src. > > Thus I would like to know your thoughts about this project, if it is > > viable, and what can be done to > > overcome these 8 Kb limit. > > One option is to not support MBR and only support GPT for this... w/ > GPT we do not have the 8k limitation (and actually the limit is 7.5k > as .5k has historically been used for MBR boot code/partition table > in the dangerously dedicated mode)... > > 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... > > -- > John-Mark Gurney Voice: +1 415 225 5579 > > "All that I will do, has been done, All that I have, has not." >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAKN1MR4D-hdX0Koy45LSg_zo-uvLi=njyPwSfYcVBYi5FT_C=w>