From nobody Thu Aug 11 18:23:59 2022 X-Original-To: dev-commits-src-all@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4M3Zvb5Zdkz4ZNFh for ; Thu, 11 Aug 2022 18:24:11 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ua1-x933.google.com (mail-ua1-x933.google.com [IPv6:2607:f8b0:4864:20::933]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4M3Zvb5HY0z4GsL for ; Thu, 11 Aug 2022 18:24:11 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-ua1-x933.google.com with SMTP id y22so7260435uay.1 for ; Thu, 11 Aug 2022 11:24:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=jFeSDOa13lVMXKtPz3sd2DprJ8TpI2PxxUWS16BCx1w=; b=xT3vhlj1qkVyZ8WMTyi1KfNDs3ETnh36Pt+HAq7Gz5jtOsmZkIPDLtzuNX/eaZISNj tNPwx2HuX7iC7/tvgr3rKIy8qLzC7VezBFisgfRRg2ZZ4eORsJNM3Tm+uXLHadu0d1Le 67l0X+8MtrpeRycVtAFjTb+mYf4UFv1ETQWgTBlziQICy5/nlJB7Pd6XwMBCXRV8F6fr VitBBZNYYLmZ+uzHy3t1Js2QE/bm2Mj7OddlrgB5jBaEJQMUxaY41MkXUUbmEL3z7cq0 HT2/MSXWOTShi+ZRKjUlV/W712+HeFIw3/P+eSCXi4NCF02mzn7Q0k5xEu3vmbsDgVgZ NgSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=jFeSDOa13lVMXKtPz3sd2DprJ8TpI2PxxUWS16BCx1w=; b=WIrv79CM7cDcpPq27YCMqFnRSupiIZlbX6FkoVxHWzFbLntmLvdzX2OlU3a1PEpaUO Vmvn8ZL5dapmmc1Q5Py31uausUPseBXX8lbi7n12ilfZXSKy4DzFtcvNRqJ+Dwl4XKG1 KYGnzO4p6x8kmHlVe/KJkK+CqxlDxX8Y84YAv8w1viugQQYGZI50MskQ86RQs1ztEcyo bMVJG+3iqIfBp2VBtQV79u01g4O9jfEe3NLwo9yApTcv1YaMR1YyFXDJ35/uTHJr54ue CODHrKERJkWCwec/CK6ivENTD47ZvqofSYByeiWZ31COFhxvtExE74xmKnxeeC/+S8Oi jB+Q== X-Gm-Message-State: ACgBeo2Qcve+4YjYYg+29Q0G5A2ktpvAEqXAmJ8QLkt6drh/GO/X3z2V +rSDOZ/NW0+llnc+SjXi3QcyC65TuCZRx0srT3e6GQ== X-Google-Smtp-Source: AA6agR7IGAYVwMBFsGM3ednr/BFQXCN+HEjYQ3iJIGpX9mRoR3EPwjdNQw+hy8ZOfDk8pPBCD6ub3+doei0DGyoNdjk= X-Received: by 2002:ab0:3bc6:0:b0:381:c4db:ef5 with SMTP id q6-20020ab03bc6000000b00381c4db0ef5mr233630uaw.81.1660242250827; Thu, 11 Aug 2022 11:24:10 -0700 (PDT) List-Id: Commit messages for all branches of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-src-all@freebsd.org X-BeenThere: dev-commits-src-all@freebsd.org MIME-Version: 1.0 References: <202208110331.27B3Va7M007335@gitrepo.freebsd.org> <20220811202204.106f7188@thor.intern.walstatt.dynvpn.de> In-Reply-To: <20220811202204.106f7188@thor.intern.walstatt.dynvpn.de> From: Warner Losh Date: Thu, 11 Aug 2022 12:23:59 -0600 Message-ID: Subject: Re: git: 39fdad34e220 - main - stand: impose 510,000 byte limit for /boot/loader and /boot/pxeldr To: FreeBSD User Cc: Warner Losh , src-committers , "" , dev-commits-src-main@freebsd.org Content-Type: multipart/alternative; boundary="0000000000009a1ded05e5fb4574" X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Rspamd-Queue-Id: 4M3Zvb5HY0z4GsL X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N --0000000000009a1ded05e5fb4574 Content-Type: text/plain; charset="UTF-8" On Thu, Aug 11, 2022 at 12:22 PM FreeBSD User wrote: > Am Thu, 11 Aug 2022 03:31:36 GMT > Warner Losh schrieb: > > > The branch main has been updated by imp: > > > > URL: > https://cgit.FreeBSD.org/src/commit/?id=39fdad34e220c52a433e78f20c8c39412429014e > > > > commit 39fdad34e220c52a433e78f20c8c39412429014e > > Author: Warner Losh > > AuthorDate: 2022-08-11 03:19:01 +0000 > > Commit: Warner Losh > > 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 > > > > 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 --0000000000009a1ded05e5fb4574 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Aug 11, 2022 at 12:22 PM Free= BSD User <freebsd@walstatt-de.= de> wrote:
https://= cgit.FreeBSD.org/src/commit/?id=3D39fdad34e220c52a433e78f20c8c39412429014e<= /a>
>
> commit 39fdad34e220c52a433e78f20c8c39412429014e
> Author:=C2=A0 =C2=A0 =C2=A0Warner Losh <imp@FreeBSD.org>
> AuthorDate: 2022-08-11 03:19:01 +0000
> Commit:=C2=A0 =C2=A0 =C2=A0Warner Losh <imp@FreeBSD.org>
> CommitDate: 2022-08-11 03:29:20 +0000
>
>=C2=A0 =C2=A0 =C2=A0stand: impose 510,000 byte limit for /boot/loader a= nd /boot/pxeldr
>=C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0The BIOS method of booting imposes an absolute limi= t of 640k for the
>=C2=A0 =C2=A0 =C2=A0size of the program being run due to btx. In practi= ce, this means that
>=C2=A0 =C2=A0 =C2=A0programs larger than about 500kiB will fail in odd = ways as the stack /
>=C2=A0 =C2=A0 =C2=A0heap will overflow.
>=C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0Pick 510,000 as the cutoff line semi-arbitrarily. l= oader_lua is now
>=C2=A0 =C2=A0 =C2=A0almost too big and we want to break the build when = it crosses this
>=C2=A0 =C2=A0 =C2=A0threshold. In my experience, below 500,000 always w= orks, above 520,000
>=C2=A0 =C2=A0 =C2=A0always seems to fail with things getting bad somewh= ere between 512,000
>=C2=A0 =C2=A0 =C2=A0to 515,000. 510,000 is as close to the line as I th= ink we can go, though
>=C2=A0 =C2=A0 =C2=A0experience may dictate we need to lower this in the= future.
>=C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0This is at-best a stop-breakage until we have a bet= ter way to subset the
>=C2=A0 =C2=A0 =C2=A0boot loader for BIOS booting to allow better, more = fined-tuned
>=C2=A0 =C2=A0 =C2=A0/boot/loaders for the many different environments t= hey have to run
>=C2=A0 =C2=A0 =C2=A0in. This likely means we'll have a graphical lo= ader than understands a
>=C2=A0 =C2=A0 =C2=A0few filesystmes for installation, and a non-graphic= al loader that
>=C2=A0 =C2=A0 =C2=A0understands the most filesystems possible for every= thing else in the
>=C2=A0 =C2=A0 =C2=A0future. Our build infrastructure needs some work be= fore we can do that,
>=C2=A0 =C2=A0 =C2=A0however.
>=C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0At this late date, it likely isn't worth the ef= forts to move parts of
>=C2=A0 =C2=A0 =C2=A0the loader into high memory. There's a number o= f assumptions about where
>=C2=A0 =C2=A0 =C2=A0the stack is, where buffers reside, etc that are fu= lfilled when it lives
>=C2=A0 =C2=A0 =C2=A0in the first 640k that would need bounce buffers an= d/or other counter
>=C2=A0 =C2=A0 =C2=A0measures if we were to split it up. All BIOS calls = are done in 16-bit
>=C2=A0 =C2=A0 =C2=A0mode with SEG:OFF addresses, requiring them to be i= n the first 640k of
>=C2=A0 =C2=A0 =C2=A0RAM. And nearly all machines in the last decade can= boot with UEFI
>=C2=A0 =C2=A0 =C2=A0(though there's some exceptions, so it isn'= t worth killing outright
>=C2=A0 =C2=A0 =C2=A0yet).
>=C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0Sponsored by:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Netflix
>=C2=A0 =C2=A0 =C2=A0Reviewed by:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 kevans
>=C2=A0 =C2=A0 =C2=A0Differential Revision:=C2=A0 https://revie= ws.freebsd.org/D36129
> ---
>=C2=A0 stand/i386/loader/Makefile | 5 +++++
>=C2=A0 stand/i386/pxeldr/Makefile | 3 +++
>=C2=A0 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=3D=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0${LOADER}.sym
>=C2=A0 INTERNALPROG=3D
>=C2=A0 NEWVERSWHAT?=3D=C2=A0 =C2=A0 =C2=A0 =C2=A0 "bootstrap loade= r" x86
>=C2=A0 VERSION_FILE=3D=C2=A0 =C2=A0 =C2=A0 =C2=A0 ${.CURDIR}/../loader/= version
> +LOADERSIZE=3D=C2=A0 510000=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 # Larges= t known safe size
> +
>=C2=A0
>=C2=A0 .PATH:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0${B= OOTSRC}/i386/loader
>=C2=A0
> @@ -79,9 +81,12 @@ CFLAGS+=3D=C2=A0 =C2=A0-I${BOOTSRC}/i386
>=C2=A0 8x16.c: ${SRCTOP}/contrib/terminus/ter-u16b.bdf
>=C2=A0 =C2=A0 =C2=A0 =C2=A0vtfontcvt -f compressed-source -o ${.TARGET}= ${.ALLSRC}
>=C2=A0
> +
>=C2=A0 ${LOADER}: ${LOADER}.bin ${BTXLDR} ${BTXKERN}
>=C2=A0 =C2=A0 =C2=A0 =C2=A0btxld -v -f elf -e ${LOADER_ADDRESS} -o ${.T= ARGET} -l ${BTXLDR} \
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-b ${BTXKERN} ${= LOADER}.bin
> +=C2=A0 =C2=A0 =C2=A0@set -- `${SIZE} ${.TARGET} | tail -1` ; x=3D$$((= ${LOADERSIZE}-$$4)); \
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0echo "$$x bytes available"= ;; test $$x -ge 0
>=C2=A0
>=C2=A0 ${LOADER}.bin: ${LOADER}.sym
>=C2=A0 =C2=A0 =C2=A0 =C2=A0${STRIPBIN} -R .comment -R .note -o ${.TARGE= T} ${.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=3D=C2=A0 =C2=A0 =C2=A0 =C2=A0pxeboot
>=C2=A0 LDR=3D pxeldr
>=C2=A0 ORG=3D 0x7c00
>=C2=A0 LOADER=3D=C2=A0 =C2=A0 =C2=A0 loader
> +PXELDRSIZE=3D 510000=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0# Larges= t known safe size
>=C2=A0
>=C2=A0 .if defined(BOOT_PXELDR_PROBE_KEYBOARD)
>=C2=A0 CFLAGS+=3D-DPROBE_KEYBOARD
> @@ -41,5 +42,7 @@ CLEANFILES+=3D ${LOADER}
>=C2=A0 ${LOADER}: ${LOADERBIN} ${BTXLDR} ${BTXKERN}
>=C2=A0 =C2=A0 =C2=A0 =C2=A0btxld -v -f elf -e ${LOADER_ADDRESS} -o ${.T= ARGET} -l ${BTXLDR} \
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-b ${BTXKERN} ${LOADERBIN}
> +=C2=A0 =C2=A0 =C2=A0@set -- `${SIZE} ${.TARGET} | tail -1` ; x=3D$$((= ${PXELDRSIZE}-$$4)); \
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0echo "$$x bytes available"= ;; test $$x -ge 0
>=C2=A0
>=C2=A0 .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:

[...]

=3D=3D=3D> 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=C2=A0 -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: v= er=3D1.02 size=3D690
load=3D9000 entry=3D9010 map=3D16M pgctl=3D0:84 client: fmt=3Delf size=3D8a= 3f0 text=3D836bc data=3D5238
bss=3D8070 entry=3D0 output: fmt=3Delf size=3D8ae39 text=3D289 data=3D8aa80= org=3D200000 entry=3D200000
-58585 bytes available 6.64 real=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
8.48 user=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02.84 sys
I'm sorry, but however you are building /boot/loader, it w= on't work when it's that big. What are your settings that increase = its size by so much?

Warner
--0000000000009a1ded05e5fb4574--