Re: git: 39fdad34e220 - main - stand: impose 510,000 byte limit for /boot/loader and /boot/pxeldr

On Thu, Aug 11, 2022 at 12:22 PM FreeBSD User <freebsd@walstatt-de.de>
wrote:

> Am Thu, 11 Aug 2022 03:31:36 GMT
> Warner Losh <imp@FreeBSD.org> schrieb:
>
> > The branch main has been updated by imp:
> >
> > URL:
> https://cgit.FreeBSD.org/src/commit/?id=39fdad34e220c52a433e78f20c8c39412429014e
> >
> > commit 39fdad34e220c52a433e78f20c8c39412429014e
> > Author:     Warner Losh <imp@FreeBSD.org>
> > AuthorDate: 2022-08-11 03:19:01 +0000
> > Commit:     Warner Losh <imp@FreeBSD.org>
> > CommitDate: 2022-08-11 03:29:20 +0000
> >
> >     stand: impose 510,000 byte limit for /boot/loader and /boot/pxeldr
> >
> >     The BIOS method of booting imposes an absolute limit of 640k for the
> >     size of the program being run due to btx. In practice, this means
> that
> >     programs larger than about 500kiB will fail in odd ways as the stack
> /
> >     heap will overflow.
> >
> >     Pick 510,000 as the cutoff line semi-arbitrarily. loader_lua is now
> >     almost too big and we want to break the build when it crosses this
> >     threshold. In my experience, below 500,000 always works, above
> 520,000
> >     always seems to fail with things getting bad somewhere between
> 512,000
> >     to 515,000. 510,000 is as close to the line as I think we can go,
> though
> >     experience may dictate we need to lower this in the future.
> >
> >     This is at-best a stop-breakage until we have a better way to subset
> the
> >     boot loader for BIOS booting to allow better, more fined-tuned
> >     /boot/loaders for the many different environments they have to run
> >     in. This likely means we'll have a graphical loader than understands
> a
> >     few filesystmes for installation, and a non-graphical loader that
> >     understands the most filesystems possible for everything else in the
> >     future. Our build infrastructure needs some work before we can do
> that,
> >     however.
> >
> >     At this late date, it likely isn't worth the efforts to move parts of
> >     the loader into high memory. There's a number of assumptions about
> where
> >     the stack is, where buffers reside, etc that are fulfilled when it
> lives
> >     in the first 640k that would need bounce buffers and/or other counter
> >     measures if we were to split it up. All BIOS calls are done in 16-bit
> >     mode with SEG:OFF addresses, requiring them to be in the first 640k
> of
> >     RAM. And nearly all machines in the last decade can boot with UEFI
> >     (though there's some exceptions, so it isn't worth killing outright
> >     yet).
> >
> >     Sponsored by:           Netflix
> >     Reviewed by:            kevans
> >     Differential Revision:  https://reviews.freebsd.org/D36129
> > ---
> >  stand/i386/loader/Makefile | 5 +++++
> >  stand/i386/pxeldr/Makefile | 3 +++
> >  2 files changed, 8 insertions(+)
> >
> > diff --git a/stand/i386/loader/Makefile b/stand/i386/loader/Makefile
> > index 3685281ffd2c..cde1513aac06 100644
> > --- a/stand/i386/loader/Makefile
> > +++ b/stand/i386/loader/Makefile
> > @@ -19,6 +19,8 @@ PROG=               ${LOADER}.sym
> >  INTERNALPROG=
> >  NEWVERSWHAT?=        "bootstrap loader" x86
> >  VERSION_FILE=        ${.CURDIR}/../loader/version
> > +LOADERSIZE=  510000          # Largest known safe size
> > +
> >
> >  .PATH:               ${BOOTSRC}/i386/loader
> >
> > @@ -79,9 +81,12 @@ CFLAGS+=   -I${BOOTSRC}/i386
> >  8x16.c: ${SRCTOP}/contrib/terminus/ter-u16b.bdf
> >       vtfontcvt -f compressed-source -o ${.TARGET} ${.ALLSRC}
> >
> > +
> >  ${LOADER}: ${LOADER}.bin ${BTXLDR} ${BTXKERN}
> >       btxld -v -f elf -e ${LOADER_ADDRESS} -o ${.TARGET} -l ${BTXLDR} \
> >               -b ${BTXKERN} ${LOADER}.bin
> > +     @set -- `${SIZE} ${.TARGET} | tail -1` ;
> x=$$((${LOADERSIZE}-$$4)); \
> > +         echo "$$x bytes available"; test $$x -ge 0
> >
> >  ${LOADER}.bin: ${LOADER}.sym
> >       ${STRIPBIN} -R .comment -R .note -o ${.TARGET} ${.ALLSRC}
> > diff --git a/stand/i386/pxeldr/Makefile b/stand/i386/pxeldr/Makefile
> > index a44dc0de2885..f8bc1eae9a31 100644
> > --- a/stand/i386/pxeldr/Makefile
> > +++ b/stand/i386/pxeldr/Makefile
> > @@ -13,6 +13,7 @@ BOOT=       pxeboot
> >  LDR= pxeldr
> >  ORG= 0x7c00
> >  LOADER=      loader
> > +PXELDRSIZE= 510000           # Largest known safe size
> >
> >  .if defined(BOOT_PXELDR_PROBE_KEYBOARD)
> >  CFLAGS+=-DPROBE_KEYBOARD
> > @@ -41,5 +42,7 @@ CLEANFILES+= ${LOADER}
> >  ${LOADER}: ${LOADERBIN} ${BTXLDR} ${BTXKERN}
> >       btxld -v -f elf -e ${LOADER_ADDRESS} -o ${.TARGET} -l ${BTXLDR} \
> >           -b ${BTXKERN} ${LOADERBIN}
> > +     @set -- `${SIZE} ${.TARGET} | tail -1` ;
> x=$$((${PXELDRSIZE}-$$4)); \
> > +         echo "$$x bytes available"; test $$x -ge 0
> >
> >  .include <bsd.prog.mk>
> >
>
> On recent CURRENT (FreeBSD 14.0-CURRENT #10 main-n257258-348164aa9e5d: Wed
> Aug 10 22:39:17
> CEST 2022 amd64), buildworld fails here on several boxes:
>
> [...]
>
> ===> lib/flua/libjail (all)
> --- all_subdir_stand ---
> --- loader ---
> btxld -v -f elf -e 0x200000 -o loader -l
> /usr/obj/usr/src/amd64.amd64/stand/i386/btx/btxldr/btxldr  -b
> /usr/obj/usr/src/amd64.amd64/stand/i386/btx/btx/btx
> /usr/obj/usr/src/amd64.amd64/stand/i386/loader_lua/loader_lua.bin kernel:
> ver=1.02 size=690
> load=9000 entry=9010 map=16M pgctl=0:84 client: fmt=elf size=8a3f0
> text=836bc data=5238
> bss=8070 entry=0 output: fmt=elf size=8ae39 text=289 data=8aa80 org=200000
> entry=200000
> -58585 bytes available 6.64 real
> 8.48 user         2.84 sys
>

I'm sorry, but however you are building /boot/loader, it won't work when
it's that big. What are your settings that increase its size by so much?

Warner