Date: Wed, 31 May 2023 12:15:12 -0600 From: Warner Losh <imp@bsdimp.com> To: FreeBSD User <freebsd@walstatt-de.de> Cc: FreeBSD CURRENT <freebsd-current@freebsd.org> Subject: Re: WITH_BEARSSL: -8112 bytes available Message-ID: <CANCZdfo-PojzQrL5ppxSLLfp%2B5f-ToqQD_N3p3aYtEKBodQ7xQ@mail.gmail.com> In-Reply-To: <20230529105854.1903226d@thor.intern.walstatt.dynvpn.de> References: <20230529105854.1903226d@thor.intern.walstatt.dynvpn.de>
next in thread | previous in thread | raw e-mail | index | archive | help
--000000000000abbc5b05fd014d59 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, May 29, 2023 at 2:59=E2=80=AFAM FreeBSD User <freebsd@walstatt-de.d= e> wrote: > Hello, > > on CURRENT, enabling in /etc/src.conf > > WITH_BEARSSL=3D > > seems to result in a slightly enlarged loader binary, which seems to have > a fixed size > supposed on the error I get. See below. > > The system is amd64 (64 bit), for the record. > > Somewhere in the past developers mentioned this upcoming problem and > provided a knob to adjust > the used size - I forgot about that knob and I couldn't find it even in > the loader docs - or > looked at the wrong places. > > Can someone help me out here? > > The first error stops compileing world/kernel, but taking a second run, > the error goes away. > > Kind regards and thanks in advance, > > oh > > > > [...] > --- all_subdir_stand/efi --- > SOURCE_DATE_EPOCH=3D1451606400 objcopy -j .peheader -j .text -j .sdata -= j > .data -j .dynamic -j > .dynsym -j .rel.dyn -j .rela.dyn -j .reloc -j .eh_frame -j > set_Xcommand_set -j > set_Xficl_compile_set --output-target=3Defi-app-x86_64 loader_4th.sym > loader_4th.efi --- > all_subdir_stand/i386 --- > > -8112 bytes available 7.71 real 12.86 user 3.08 sys bummer. I hate it when it's that close. You can try setting LOADERSIZE=3D560000 in your environment. We currently s= et the maximum to 550,000 bytes because that's the most conservative number due to variation in the available BIOS space available. This likely can be set even higher if you don't have add-in cards that are consuming space in the lower 640k of memory. 640k is the absolute limit, but you need 20-30k of stack for the loader so pushing this much past 625,000 or maybe 630,000 increases the risk of run-time crashes as the stack smashes through the top of the loader program. You may also have to disable the lua build, since it uses more stack and is just a smidge larger than the forth build. _simp will be the smallest of them all. On my system, without bearssl, I see: -r-xr-xr-x 3 root wheel 503808 May 22 15:25 /boot/loader_lua -r-xr-xr-x 1 root wheel 446464 May 22 15:25 /boot/loader_4th -r-xr-xr-x 1 root wheel 385024 May 22 15:25 /boot/loader_simp which suggests a ~60k bump for adding forth and ~115k bump for lua. So the 560,000 may need to be 625,000 which is living life on the edge for 4th, and simply too big for lua. I'd be open to adding docs on this, since I don't think this option is currently documented since I added it to experiment around with a good value. And no, I really do not want to support 'loadable modules'. BIOS booting is on the way out, and people that want to do complex stuff in the boot loader will simply have to do that in UEFI or maybe kboot/LinuxBoot. There's low RoI on adding this complexity, imho. We'd be better off, imho, making things like the graphics console optional since the fonts and code for that free up about 30k in stupid experiments that I've done (it's hard since vidconsole has a lot of calls into the graphics system that aren't optional and easy to disable, so I've had to do hack and slash to produce a super ugly result that is only suggestive of the final savings): -rw-r--r-- 1 imp imp 352256 May 31 12:04 loader_simp I don't know if I slashed too much, or not enough since the code is rather hard to separate out, so if you really wanted to go down this path, it would take a lot of work and patient understanding to make it so with the low end of savings 20k and the high end on the order of maybe 40k. There's likely other ways to conserve space. We've not had space issues with loader, et al, in the past, so it's not well setup for subsetting. Though the different filesystem support might also net you a fair amount: LOADER_NET_SUPPORT?=3D yes LOADER_NFS_SUPPORT?=3D yes LOADER_TFTP_SUPPORT?=3D yes LOADER_CD9660_SUPPORT?=3D yes LOADER_EXT2FS_SUPPORT?=3D yes LOADER_MSDOS_SUPPORT?=3D yes LOADER_UFS_SUPPORT?=3D yes LOADER_GZIP_SUPPORT?=3D yes LOADER_BZIP2_SUPPORT?=3D yes as would compiling w/o ZFS, which uses its own method (eg WITHOUT_LOADER_ZFS). Tuning the loader at this level does start to get into the weeds a bit, but can offer ~40k savings turning off all but NET and UFS: -rw-r--r-- 1 imp imp 344064 May 31 12:11 loader_simp you get even about ~100k when you disable ZFS support with -DWITHOUT_LOADER_ZFS: -rw-r--r-- 1 imp imp 241664 May 31 12:12 loader_simp (both of these are with the graphics console enabled without the silly hacks to see how much that takes up). Without the extras and ZFS, you might have bearssl and lua together even... Hope this helps. Warner --000000000000abbc5b05fd014d59 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">= <div dir=3D"ltr" class=3D"gmail_attr">On Mon, May 29, 2023 at 2:59=E2=80=AF= AM FreeBSD User <<a href=3D"mailto:freebsd@walstatt-de.de">freebsd@walst= att-de.de</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style= =3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding= -left:1ex">Hello,<br> <br> on CURRENT, enabling in /etc/src.conf<br> <br> WITH_BEARSSL=3D<br> <br> seems to result in a slightly enlarged loader binary, which seems to have a= fixed size<br> supposed on the error I get. See below.<br> <br> The system is amd64 (64 bit), for the record.<br> <br> Somewhere in the past developers mentioned this upcoming problem and provid= ed a knob to adjust<br> the used size - I forgot about that knob and I couldn't find it even in= the loader docs - or<br> looked at the wrong places.<br> <br> Can someone help me out here?<br> <br> The first error stops compileing world/kernel, but taking a second run, the= error goes away.<br> <br> Kind regards and thanks in advance,<br> <br> oh<br> <br> <br> <br> [...]<br> --- all_subdir_stand/efi ---<br> SOURCE_DATE_EPOCH=3D1451606400=C2=A0 objcopy -j .peheader -j .text -j .sdat= a -j .data=C2=A0 -j .dynamic -j<br> .dynsym -j .rel.dyn=C2=A0 -j .rela.dyn -j .reloc -j .eh_frame -j set_Xcomma= nd_set=C2=A0 -j<br> set_Xficl_compile_set=C2=A0 --output-target=3Defi-app-x86_64 loader_4th.sym= loader_4th.efi ---<br> all_subdir_stand/i386 --- <br> <br> -8112 bytes available 7.71 real=C2=A0 =C2=A0 =C2=A0 =C2=A0 12.86 user=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A03.08 sys</blockquote><div><br></div><div>bummer= . I hate it when it's that close.</div><div><br></div><div>You can try = setting LOADERSIZE=3D560000 in your environment. We currently set the maxim= um to 550,000</div><div>bytes because that's the most conservative numb= er due to variation in the available BIOS space available.</div><div>This l= ikely can be set even higher if you don't have add-in cards that are co= nsuming space in the lower 640k</div><div>of memory. 640k is the absolute l= imit, but you need 20-30k of stack for the loader so pushing this much past= </div><div>625,000 or maybe 630,000 increases the risk of run-time crashes = as the stack smashes through the top of</div><div>the loader program. You m= ay also have to disable the lua build, since it uses more stack and is just= a smidge</div><div>larger than the forth build. _simp will be the smallest= of them all. On my system, without bearssl, I see:</div><div>-r-xr-xr-x = =C2=A03 root =C2=A0wheel =C2=A0503808 May 22 15:25 /boot/loader_lua<br></di= v><div>-r-xr-xr-x =C2=A01 root =C2=A0wheel =C2=A0446464 May 22 15:25 /boot/= loader_4th<br></div><div>-r-xr-xr-x =C2=A01 root =C2=A0wheel =C2=A0385024 M= ay 22 15:25 /boot/loader_simp<br></div><div>which suggests a ~60k bump for = adding forth and ~115k bump for lua. So the 560,000 may need to be 625,000<= /div><div>which is living life on the edge for 4th, and simply too big for = lua.</div><div><br></div><div>I'd be open to adding docs on this, since= I don't think this option is currently documented since I added it</di= v><div>to experiment around with a good value.</div><div><br></div><div>And= no, I really do not want to support 'loadable modules'. BIOS booti= ng is on the way out, and people</div><div>that want to do complex stuff in= the boot loader will simply have to do that in UEFI or maybe kboot/LinuxBo= ot.</div><div>There's low RoI on adding this complexity, imho. We'd= be better off, imho, making things like the graphics</div><div>console opt= ional since the fonts and code for that free up about 30k in stupid experim= ents that I've done</div><div>(it's hard since vidconsole has a lot= of calls into the graphics system that aren't optional and easy to dis= able,</div><div>so I've had to do hack and slash to produce a super ugl= y result that is only suggestive of the final savings):</div><div>-rw-r--r-= - =C2=A01 imp =C2=A0imp =C2=A0352256 May 31 12:04 loader_simp<br></div><div= >I don't know if I slashed too much, or not enough since the code is ra= ther hard to separate out, so if you</div><div>really wanted to go down thi= s path, it would take a lot of work and patient understanding to make it so= with</div><div>the low end of savings 20k and the high end on the order of= maybe 40k.</div><div><br></div><div>There's likely other ways to conse= rve space. We've not had space issues with loader, et al, in the past,<= /div><div>so it's not well setup for subsetting. Though the different f= ilesystem support might also net you a fair amount:</div><div>LOADER_NET_SU= PPORT?=3D =C2=A0 =C2=A0yes<br>LOADER_NFS_SUPPORT?=3D =C2=A0 =C2=A0yes<br>LO= ADER_TFTP_SUPPORT?=3D =C2=A0 yes<br>LOADER_CD9660_SUPPORT?=3D yes<br>LOADER= _EXT2FS_SUPPORT?=3D yes<br>LOADER_MSDOS_SUPPORT?=3D =C2=A0yes<br>LOADER_UFS= _SUPPORT?=3D =C2=A0 =C2=A0yes<br>LOADER_GZIP_SUPPORT?=3D =C2=A0 yes<br>LOAD= ER_BZIP2_SUPPORT?=3D =C2=A0yes<br></div><div>as would compiling w/o ZFS, wh= ich uses its own method (eg WITHOUT_LOADER_ZFS). Tuning the loader</div><di= v>at this level does start to get into the weeds a bit, but can offer ~40k = savings turning off all but NET and UFS:</div><div>-rw-r--r-- =C2=A01 imp = =C2=A0imp =C2=A0344064 May 31 12:11 loader_simp<br></div><div>you get even = about ~100k when you disable ZFS support with -DWITHOUT_LOADER_ZFS:</div><d= iv>-rw-r--r-- =C2=A01 imp =C2=A0imp =C2=A0241664 May 31 12:12 loader_simp<b= r></div><div>(both of these are with the graphics console enabled without t= he silly hacks to see how much that takes up).</div><div>Without the extras= and ZFS, you might have bearssl and lua together even...</div><div><br></d= iv><div>Hope this helps.</div><div><br></div><div>Warner<br></div></div></d= iv> --000000000000abbc5b05fd014d59--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfo-PojzQrL5ppxSLLfp%2B5f-ToqQD_N3p3aYtEKBodQ7xQ>