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

From: FreeBSD User <freebsd_at_walstatt-de.de>
Date: Thu, 11 Aug 2022 19:07:15 UTC
Am Thu, 11 Aug 2022 20:56:05 +0200
FreeBSD User <freebsd@walstatt-de.de> schrieb:

> Am Thu, 11 Aug 2022 12:46:46 -0600
> Warner Losh <imp@bsdimp.com> schrieb:
> 
> > On Thu, Aug 11, 2022 at 12:45 PM FreeBSD User <freebsd@walstatt-de.de>
> > wrote:
> >   
> > > Am Thu, 11 Aug 2022 20:42:57 +0200
> > > FreeBSD User <freebsd@walstatt-de.de> schrieb:
> > >    
> > > > 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
> > > >
> > > >    
> > > The src.conf:
> > >
> > > # more /etc/src.conf
> > > #
> > > CPUTYPE?=                       native
> > > #
> > > CFLAGS+=                        -O3
> > > # for the kernel
> > > COPTFLAGS+=                     -O3
> > > #
> > > #CXXFLAGS+=                     -std=c++20
> > > #
> > > WITH_CLANG_EXTRAS=              YES
> > > #WITH_LLVM_BINUTILS=            YES
> > > #
> > > #WITH_BSD_GREP=                 YES
> > > #
> > > WITH_OFED_EXTRA=                YES
> > > #WITH_CTF=                              YES
> > > #
> > > WITH_BEARSSL=                   YES
> > >    
> > 
> > I think this is the only thing that will affect things. what happens if you
> > turn this off?
> > 
> > Warner  
> 
> Well, I would have asked whether BEARSSL could trigger something ... I can't change this so
> easily, whenever I switch it on or of, I usually have to recompile world beginning from a
> cleanworld ... this takes approx two hours on my superfast Ivy bridge 4 core crap box ...


I was wrong, something has happend with the build tree in the past months since I fiddled
arounf with BEARSSL knob:

essence is: now the build is complete.

But isn't the BEARSSL knob essential for the secure boot features? I was playing around a
while ago, but do not use anything reasonable out of it ...

> 
> > 
> > #  
> > > WITH_SORT_THREADS=              YES
> > > #
> > > WITH_ZONEINFO_LEAPSECONDS_SUPPORT=      YES
> > > #
> > > WITH_MALLOC_PRODUCTION= YES
> > > #
> > > WITHOUT_ASSERT_DEBUG=   YES
> > > WITHOUT_TESTS=          YES
> > > WITHOUT_DEBUG_FILES=    YES
> > > #
> > > WITHOUT_CLEAN=                  YES
> > > #
> > > WITHOUT_REPRODUCIBLE_BUILD=     YES
> > > #
> > > INSTALL_NODEBUG=                YES
> > > #
> > >
> > >
> > >
> > >
> > > --
> > > O. Hartmann
> > >    
> 
> 
> 



-- 
O. Hartmann