From nobody Sat Jun 3 15:02:49 2023 X-Original-To: freebsd-current@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 4QYNRJ2jHhz4Z04J for ; Sat, 3 Jun 2023 15:03:24 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from smtp052.goneo.de (smtp052.goneo.de [85.220.129.60]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4QYNRH0Sj8z4JcZ for ; Sat, 3 Jun 2023 15:03:22 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=walstatt-de.de header.s=DKIM001 header.b=B00FdHdK; spf=none (mx1.freebsd.org: domain of freebsd@walstatt-de.de has no SPF policy when checking 85.220.129.60) smtp.mailfrom=freebsd@walstatt-de.de; dmarc=none Received: from hub2.goneo.de (hub2.goneo.de [IPv6:2001:1640:5::8:53]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by smtp5.goneo.de (Postfix) with ESMTPS id 5FD3910A1E88; Sat, 3 Jun 2023 17:03:19 +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 (4096 bits)) (No client certificate requested) by hub2.goneo.de (Postfix) with ESMTPS id BD6AB10A3337; Sat, 3 Jun 2023 17:03:17 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walstatt-de.de; s=DKIM001; t=1685804597; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=A5B9wXa+oRAC1v16vroDQgVdP1UTVcMmFzOnR097wPE=; b=B00FdHdKMuTjHrtPEpYHrXOBWR8CczZBLfGUefIujZuKrR1Bjvef+Y/N+r6YeIYgn/Q4D2 WqKs6UTdgdfWLZ37ZQz37plb5nQliCnub4UeMQEQQEW40kBzEKmOZOnhRmEQVmwshy2fCE zVf6YyyTQm8PYM0ZiY07tdGgd0ckMWr9QJ6/v0Rd3iYYNa/ol4Wv4BN9FUW7bDNhMp/Iga 46CL7Njnaqb4HqU1+FZvGR/fwnSARZ2DX1ncNB9NafsefzycPSu/G4OiOUSUCJCgfpGP/A PCbg+E5PSK05DkoVmO4drI6KakdU+JdOoLIa4SdL/bA60SbVWRAB2QE4b6bM0g== Received: from thor.intern.walstatt.dynvpn.de (dynamic-077-191-239-118.77.191.pool.telefonica.de [77.191.239.118]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by hub2.goneo.de (Postfix) with ESMTPSA id 7860110A3332; Sat, 3 Jun 2023 17:03:16 +0200 (CEST) Date: Sat, 3 Jun 2023 17:02:49 +0200 From: FreeBSD User To: Warner Losh Cc: FreeBSD CURRENT Subject: Re: WITH_BEARSSL: -8112 bytes available Message-ID: <20230603170316.74ea78f1@thor.intern.walstatt.dynvpn.de> In-Reply-To: References: <20230529105854.1903226d@thor.intern.walstatt.dynvpn.de> Organization: walstatt-de.de List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-UID: f170e8 X-Rspamd-UID: 039139 X-Spamd-Result: default: False [-3.23 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.986]; NEURAL_HAM_LONG(-0.94)[-0.940]; R_DKIM_ALLOW(-0.20)[walstatt-de.de:s=DKIM001]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; R_SPF_NA(0.00)[no SPF record]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; DKIM_TRACE(0.00)[walstatt-de.de:+]; TO_MATCH_ENVRCPT_SOME(0.00)[]; ASN(0.00)[asn:25394, ipnet:85.220.128.0/17, country:DE]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; TO_DN_ALL(0.00)[]; DMARC_NA(0.00)[walstatt-de.de]; RCVD_COUNT_THREE(0.00)[4]; HAS_ORG_HEADER(0.00)[]; RCVD_TLS_ALL(0.00)[] X-Rspamd-Queue-Id: 4QYNRH0Sj8z4JcZ X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N Am Wed, 31 May 2023 12:15:12 -0600 Warner Losh schrieb: Sorry for the late response. > On Mon, May 29, 2023 at 2:59=E2=80=AFAM FreeBSD User wrote: >=20 > > Hello, > > > > on CURRENT, enabling in /etc/src.conf > > > > WITH_BEARSSL=3D > > > > seems to result in a slightly enlarged loader binary, which seems to ha= ve > > a fixed size > > supposed on the error I get. See below. > > > > The system is amd64 (64 bit), for the record. > > > > Somewhere in the past developers mentioned this upcoming problem and > > provided a knob to adjust > > the used size - I forgot about that knob and I couldn't find it even in > > the loader docs - or > > looked at the wrong places. > > > > Can someone help me out here? > > > > The first error stops compileing world/kernel, but taking a second run, > > the error goes away. > > > > Kind regards and thanks in advance, > > > > oh > > > > > > > > [...] > > --- all_subdir_stand/efi --- > > SOURCE_DATE_EPOCH=3D1451606400 objcopy -j .peheader -j .text -j .sdata= -j > > .data -j .dynamic -j > > .dynsym -j .rel.dyn -j .rela.dyn -j .reloc -j .eh_frame -j > > set_Xcommand_set -j > > set_Xficl_compile_set --output-target=3Defi-app-x86_64 loader_4th.sym > > loader_4th.efi --- > > all_subdir_stand/i386 --- > > > > -8112 bytes available 7.71 real 12.86 user 3.08 sys =20 >=20 >=20 > bummer. I hate it when it's that close. >=20 > You can try setting LOADERSIZE=3D560000 in your environment. We currently= set > the maximum to 550,000 I tried to find find anything related to LOADER or SIZE in the docs. I reme= mber you mentioned the existence of that variable months ago, but with no clue what to look af= ter, it is almost impossible yo figure out as a non developer what the right knob might be. A grep -r on /usr/src shows up only in=20 [...] ./stand/i386/loader/Makefile:LOADERSIZE?=3D 550000 # Largest= known safe size for loader.bin ./stand/i386/loader/Makefile: @set -- `ls -l ${.TARGET}` ; x=3D$$((${LOAD= ERSIZE}-$$5)); \ [...] There is no sign/trace of it in any man page related to loader and sibbling= s. I found the variable rather quickly after knowing what to look after. > bytes because that's the most conservative number due to variation in the > available BIOS space available. > This likely can be set even higher if you don't have add-in cards that are > consuming space in the lower 640k > of memory. 640k is the absolute limit, but you need 20-30k of stack for t= he > loader so pushing this much past > 625,000 or maybe 630,000 increases the risk of run-time crashes as the > stack smashes through the top of > the loader program. You may also have to disable the lua build, since it > uses more stack and is just a smidge > larger than the forth build. _simp will be the smallest of them all. On my > system, without bearssl, I see: > -r-xr-xr-x 3 root wheel 503808 May 22 15:25 /boot/loader_lua > -r-xr-xr-x 1 root wheel 446464 May 22 15:25 /boot/loader_4th > -r-xr-xr-x 1 root wheel 385024 May 22 15:25 /boot/loader_simp In my case, with supposedly blewn up loader size by BEARSSL enables, it is: -r-xr-xr-x 1 root wheel - 503808 3 Juni 12:33 /boot/loader_4th* -r-xr-xr-x 1 root wheel - 643584 3 Juni 12:33 /boot/loader_4th.efi* -r-xr-xr-x 1 root wheel - 503808 3 Juni 07:45 /boot/loader_4th.old* -r-xr-xr-x 3 root wheel - 569344 3 Juni 12:33 /boot/loader_lua* -r-xr-xr-x 2 root wheel - 737280 3 Juni 12:33 /boot/loader_lua.efi* -r-xr-xr-x 1 root wheel - 569344 3 Juni 07:45 /boot/loader_lua.old* -r-xr-xr-x 1 root wheel - 446464 3 Juni 12:33 /boot/loader_simp* -r-xr-xr-x 1 root wheel - 589312 3 Juni 12:33 /boot/loader_simp.efi* -r-xr-xr-x 1 root wheel - 446464 3 Juni 07:45 /boot/loader_simp.old* on FreeBSD 14.0-CURRENT #58 main-n263387-556b43492297: Fri Jun 2 20:19:55 = CEST 2023 amd64. > which suggests a ~60k bump for adding forth and ~115k bump for lua. So the > 560,000 may need to be 625,000 > which is living life on the edge for 4th, and simply too big for lua. >=20 > I'd be open to adding docs on this, since I don't think this option is > currently documented since I added it > to experiment around with a good value. See above, personally I'd like to see some hints on that variable, even if = I do not fiddle around with it. >=20 > And no, I really do not want to support 'loadable modules'. BIOS booting = is > on the way out, and people > that want to do complex stuff in the boot loader will simply have to do > that in UEFI or maybe kboot/LinuxBoot. > There's low RoI on adding this complexity, imho. We'd be better off, imho, > making things like the graphics > console optional since the fonts and code for that free up about 30k in > stupid experiments that I've done > (it's hard since vidconsole has a lot of calls into the graphics system > that aren't optional and easy to disable, > so I've had to do hack and slash to produce a super ugly result that is > only suggestive of the final savings): > -rw-r--r-- 1 imp imp 352256 May 31 12:04 loader_simp > I don't know if I slashed too much, or not enough since the code is rather > hard to separate out, so if you > really wanted to go down this path, it would take a lot of work and patie= nt > understanding to make it so with > the low end of savings 20k and the high end on the order of maybe 40k. >=20 > There's likely other ways to conserve space. We've not had space issues > with loader, et al, in the past, > so it's not well setup for subsetting. Though the different filesystem > support might also net you a fair amount: > LOADER_NET_SUPPORT?=3D yes > LOADER_NFS_SUPPORT?=3D yes > LOADER_TFTP_SUPPORT?=3D yes > LOADER_CD9660_SUPPORT?=3D yes > LOADER_EXT2FS_SUPPORT?=3D yes > LOADER_MSDOS_SUPPORT?=3D yes > LOADER_UFS_SUPPORT?=3D yes > LOADER_GZIP_SUPPORT?=3D yes > LOADER_BZIP2_SUPPORT?=3D yes > as would compiling w/o ZFS, which uses its own method (eg > WITHOUT_LOADER_ZFS). Tuning the loader > at this level does start to get into the weeds a bit, but can offer ~40k > savings turning off all but NET and UFS: > -rw-r--r-- 1 imp imp 344064 May 31 12:11 loader_simp > you get even about ~100k when you disable ZFS support with > -DWITHOUT_LOADER_ZFS: > -rw-r--r-- 1 imp imp 241664 May 31 12:12 loader_simp > (both of these are with the graphics console enabled without the silly > hacks to see how much that takes up). > Without the extras and ZFS, you might have bearssl and lua together even.= .. >=20 > Hope this helps. Very much appreciated, thanks. I'm not so much concerned by the space sonsumption or a corrupted boot proc= ess, I don't even know whether I really need this i386 stuff mentioned here, since all of my = boxes are UEFI, except the APU2, which are driven by SeaBIOS and bootin non UEFI. The cosmetic issue is that whenever anything reagrding the loader gets touc= hed by the compiler, out build system drops out with an error - a second run then per= forms clean (which is a kind of weird I guess). >=20 > Warner Thank you very much, Kind regards Oliver --=20 O. Hartmann