Re: git: 39fdad34e220 - main - stand: impose 510,000 byte limit for /boot/loader and /boot/pxeldr
- Reply: FreeBSD User : "Re: git: 39fdad34e220 - main - stand: impose 510,000 byte limit for /boot/loader and /boot/pxeldr"
- Reply: Warner Losh : "Re: git: 39fdad34e220 - main - stand: impose 510,000 byte limit for /boot/loader and /boot/pxeldr"
- In reply to: Warner Losh : "Re: git: 39fdad34e220 - main - stand: impose 510,000 byte limit for /boot/loader and /boot/pxeldr"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Thu, 11 Aug 2022 18:42:57 UTC
Am Thu, 11 Aug 2022 12:23:59 -0600
Warner Losh <imp@bsdimp.com> schrieb:
> 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
Hello,
I have a custom kernel with several drivers enabled, others disabled, but I'm not aware of any
knowb I triggered by purpose that could change the size. Can you help me with some hints which
knobs this might trigger? Since it happens on ALL boxes with CURRENT and different but similar
custom kernel settings (mostly driver and disabling debugging et cetera it must be something
very trivial that triggers that misbehaviour ... I doubt that kernel config is the cause, but
anyway, I'll give you some extra configs I put on one box that fails:
[... kernel conf ...]
# The defaults are 64K and 128K respectively.
options DFLTPHYS=(64*1024)
#options MAXPHYS=(512*1024)
options MAXPHYS=(1024*1024)
options CC_CDG
options CC_CHD
options CC_CUBIC
options CC_DCTCP
options CC_HD
options CC_HTCP
options CC_VEGAS
options RATELIMIT # TX rate
options ZFS # ZFS
options GEOM_NOP # NOP GEOM class
options GEOM_ELI
options LIBICONV # kernels iconv
options LIBMCHAIN # mchain library
options KGSSAPI # Kernel GSS API modulue
options MSDOSFS_ICONV # MSDOS Filesystem
options CD9660_ICONV # ISO 9660 Filesystem
options FDESCFS #File descriptor filesystem
options FUSEFS #FUSE support module
options AUTOFS # automounter filesystem
options NULLFS
#options P1003_1B_SEMAPHORES # POSIX-style semaphores
#options P1003_1B_MQUEUE # POSIX message queue
options TCPHPTS # TCP High Precission timer
#options TCPPCAP # keeps the last n packets
#options MROUTING # Multicast routing
options IPSEC # Internet Protocol Security protocol
#options TCP_SIGNATURE # #include support for RFC 2385
options SCTP # Stream Control Transmission Protocol
#
options MAC_BSDEXTENDED # ugidfw
options MAC_PORTACL #
options MAC_NTPD #
#
options CAM_IOSCHED_DYNAMIC # CAM iosched NCQ TRIM
--
O. Hartmann