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