From nobody Thu Aug 11 19:07:15 2022 X-Original-To: dev-commits-src-main@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 4M3bsv6qJ1z4Y8PL for ; Thu, 11 Aug 2022 19:07:47 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from smtp6.goneo.de (smtp6.goneo.de [IPv6:2001:1640:5::8:31]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4M3bst70Pbz3Cg8 for ; Thu, 11 Aug 2022 19:07:46 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from hub2.goneo.de (hub2.goneo.de [85.220.129.53]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by smtp6.goneo.de (Postfix) with ESMTPS id 9B6A510A332C for ; Thu, 11 Aug 2022 21:07:45 +0200 (CEST) Received: from hub2.goneo.de (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by hub2.goneo.de (Postfix) with ESMTPS id C39D010A3308 for ; Thu, 11 Aug 2022 21:07:43 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walstatt-de.de; s=DKIM001; t=1660244863; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=J+jTbtmENXhERYp6WtR3Lu1ZHtyloaGQyRQ7VqCV7Ug=; b=gs6wdoXEyPzzIRD4RLQyJx2q0eBiqrIxqSUFp430Eg1jzUROBp3F/TX+cICgy2EOyBtMkL zivW75+SZJ9OB/tnHAhxfvzDZwUsQxyyIbO5mktT6XjMD2nU7eqKHJ1DaKDleOmpO62pdX hs5zlZ7P+DceJXwYEEEp5eE6wat8Uiz4F0r3Hd1U4Ts+aWjrjJ0H6cUscEvIwDTnDvkf9h J/auJg5wKIYG2tgqZnciR9IphTTMmPnr/zuaqPDVRNdRd9pX/fI++HbtQag4UIZ2BQ97NH FUTtXSIS4sgA3hUaZbc8tlir1sIwyC+RJ24PtvJIJvHROaDlcHWsbTjLnAkKDw== Received: from thor.intern.walstatt.dynvpn.de (dynamic-078-055-077-000.78.55.pool.telefonica.de [78.55.77.0]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by hub2.goneo.de (Postfix) with ESMTPSA id 920BC10A3306 for ; Thu, 11 Aug 2022 21:07:43 +0200 (CEST) Date: Thu, 11 Aug 2022 21:07:15 +0200 From: FreeBSD User To: 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: <20220811210742.494d9a0f@thor.intern.walstatt.dynvpn.de> In-Reply-To: <20220811205632.1c7f8145@thor.intern.walstatt.dynvpn.de> References: <202208110331.27B3Va7M007335@gitrepo.freebsd.org> <20220811202204.106f7188@thor.intern.walstatt.dynvpn.de> <20220811204324.00b64b02@thor.intern.walstatt.dynvpn.de> <20220811204518.452625ea@thor.intern.walstatt.dynvpn.de> <20220811205632.1c7f8145@thor.intern.walstatt.dynvpn.de> Organization: walstatt-de.de List-Id: Commit messages for the main branch of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-main List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-src-main@freebsd.org X-BeenThere: dev-commits-src-main@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-UID: eb9214 X-Rspamd-UID: 96d75b X-Rspamd-Queue-Id: 4M3bst70Pbz3Cg8 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=walstatt-de.de header.s=DKIM001 header.b=gs6wdoXE; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd@walstatt-de.de has no SPF policy when checking 2001:1640:5::8:31) smtp.mailfrom=freebsd@walstatt-de.de X-Spamd-Result: default: False [-3.30 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[walstatt-de.de:s=DKIM001]; MIME_GOOD(-0.10)[text/plain]; DKIM_TRACE(0.00)[walstatt-de.de:+]; MLMMJ_DEST(0.00)[dev-commits-src-main@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_NA(0.00)[no SPF record]; DMARC_NA(0.00)[walstatt-de.de]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; RCPT_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:25394, ipnet:2001:1640::/32, country:DE]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; HAS_ORG_HEADER(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[dev-commits-src-main@freebsd.org]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Am Thu, 11 Aug 2022 20:56:05 +0200 FreeBSD User schrieb: > Am Thu, 11 Aug 2022 12:46:46 -0600 > Warner Losh schrieb: > > > On Thu, Aug 11, 2022 at 12:45 PM FreeBSD User > > wrote: > > > > > Am Thu, 11 Aug 2022 20:42:57 +0200 > > > FreeBSD User schrieb: > > > > > > > Am Thu, 11 Aug 2022 12:23:59 -0600 > > > > Warner Losh schrieb: > > > > > > > > > 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 > > > > > > > > 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