Date: Sat, 3 Jun 2023 17:02:49 +0200 From: FreeBSD User <freebsd@walstatt-de.de> To: Warner Losh <imp@bsdimp.com> Cc: FreeBSD CURRENT <freebsd-current@freebsd.org> Subject: Re: WITH_BEARSSL: -8112 bytes available Message-ID: <20230603170316.74ea78f1@thor.intern.walstatt.dynvpn.de> In-Reply-To: <CANCZdfo-PojzQrL5ppxSLLfp%2B5f-ToqQD_N3p3aYtEKBodQ7xQ@mail.gmail.com> References: <20230529105854.1903226d@thor.intern.walstatt.dynvpn.de> <CANCZdfo-PojzQrL5ppxSLLfp%2B5f-ToqQD_N3p3aYtEKBodQ7xQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Am Wed, 31 May 2023 12:15:12 -0600
Warner Losh <imp@bsdimp.com> schrieb:
Sorry for the late response.
> On Mon, May 29, 2023 at 2:59=E2=80=AFAM FreeBSD User <freebsd@walstatt-de=
.de> wrote:
>=20
> > Hello,
> >
> > on CURRENT, enabling in /etc/src.conf
> >
> > WITH_BEARSSL=3D
> >
> > seems to result in a slightly enlarged loader binary, which seems to ha=
ve
> > 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 =20
>=20
>=20
> bummer. I hate it when it's that close.
>=20
> You can try setting LOADERSIZE=3D560000 in your environment. We currently=
set
> the maximum to 550,000
I tried to find find anything related to LOADER or SIZE in the docs. I reme=
mber you mentioned
the existence of that variable months ago, but with no clue what to look af=
ter, it is almost
impossible yo figure out as a non developer what the right knob might be.
A grep -r on /usr/src shows up only in=20
[...]
./stand/i386/loader/Makefile:LOADERSIZE?=3D 550000 # Largest=
known safe size for
loader.bin
./stand/i386/loader/Makefile: @set -- `ls -l ${.TARGET}` ; x=3D$$((${LOAD=
ERSIZE}-$$5)); \
[...]
There is no sign/trace of it in any man page related to loader and sibbling=
s. I found the
variable rather quickly after knowing what to look after.
> 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 t=
he
> 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
In my case, with supposedly blewn up loader size by BEARSSL enables, it is:
-r-xr-xr-x 1 root wheel - 503808 3 Juni 12:33 /boot/loader_4th*
-r-xr-xr-x 1 root wheel - 643584 3 Juni 12:33 /boot/loader_4th.efi*
-r-xr-xr-x 1 root wheel - 503808 3 Juni 07:45 /boot/loader_4th.old*
-r-xr-xr-x 3 root wheel - 569344 3 Juni 12:33 /boot/loader_lua*
-r-xr-xr-x 2 root wheel - 737280 3 Juni 12:33 /boot/loader_lua.efi*
-r-xr-xr-x 1 root wheel - 569344 3 Juni 07:45 /boot/loader_lua.old*
-r-xr-xr-x 1 root wheel - 446464 3 Juni 12:33 /boot/loader_simp*
-r-xr-xr-x 1 root wheel - 589312 3 Juni 12:33 /boot/loader_simp.efi*
-r-xr-xr-x 1 root wheel - 446464 3 Juni 07:45 /boot/loader_simp.old*
on FreeBSD 14.0-CURRENT #58 main-n263387-556b43492297: Fri Jun 2 20:19:55 =
CEST 2023 amd64.
> 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.
>=20
> 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.
See above, personally I'd like to see some hints on that variable, even if =
I do not fiddle
around with it.
>=20
> 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 patie=
nt
> understanding to make it so with
> the low end of savings 20k and the high end on the order of maybe 40k.
>=20
> 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.=
..
>=20
> Hope this helps.
Very much appreciated, thanks.
I'm not so much concerned by the space sonsumption or a corrupted boot proc=
ess, I don't even
know whether I really need this i386 stuff mentioned here, since all of my =
boxes are UEFI,
except the APU2, which are driven by SeaBIOS and bootin non UEFI.
The cosmetic issue is that whenever anything reagrding the loader gets touc=
hed by the
compiler, out build system drops out with an error - a second run then per=
forms clean (which
is a kind of weird I guess).
>=20
> Warner
Thank you very much,
Kind regards
Oliver
--=20
O. Hartmann
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20230603170316.74ea78f1>