From nobody Fri Aug 02 16:35:27 2024 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 4WbBKB3D8Zz5S1jy for ; Fri, 02 Aug 2024 16:35:42 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) (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 "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WbBKB0bj1z41H8 for ; Fri, 2 Aug 2024 16:35:42 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20230601.gappssmtp.com header.s=20230601 header.b=yg+huTnx; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::1032) smtp.mailfrom=wlosh@bsdimp.com Received: by mail-pj1-x1032.google.com with SMTP id 98e67ed59e1d1-2cb510cd097so6232498a91.1 for ; Fri, 02 Aug 2024 09:35:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1722616539; x=1723221339; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=r1oAPGoVSdiHNjB5xrO+0km1ilFeSvg1qxc3tiUKp38=; b=yg+huTnx+LkKy91q73dwStAQJAJa1T43lY5L69g37xRAKYHk0ePGc+dPHNMs1HWAa7 SUh9oWY/BLyk1mNjPjIPDKOrEty+L4VpuLqqxF5FGvRHa+nsKcnqYJ/FTofdr2S3zDXO /KEKUATivdCdtwUrGAhYc/85ILmcm7FhA7NZBDtlJWEC41fmNmHUJy7CN83YM/x9l8LN VDf0U+Kz/MrY2MBhITklWERwmn5OiYxA4zXYtokf1q5aD/G3C6au2JerxmmvAsYGNJfq 3QrxydRSlhwDLBPasFqYa7xVZLbm5RDy0oZZiV6xrPxIXF1H7KGbNc6tqA9/OM2gOjPK M2GQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722616539; x=1723221339; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=r1oAPGoVSdiHNjB5xrO+0km1ilFeSvg1qxc3tiUKp38=; b=tGQNfg+cikxXxeOV2Zog72k8hneOWQvANU4/Shs9RXbNaTW9S66rPw3XSSxw7tdeQ6 6vzDZIP5Uev2w4Igyu8CwdbhvpcPrerYYsWSkRcJIWI3Rr3oByiL9E3uRyqFsHFZpR5u DgGVY4CEAB6qzKLB651Ok6vj/iu3Ie4iyA1zJwiH2FJ2YfN4wHGuu+IMj5R024ldL8j2 ewzs7BwSuWFHqCQ+8gG2ulTTpqWcgbVmADIHXzAnweGmkUOpjlQEUOOa6yynxpY3WxtB vFaSx+6R9o0ECCit49w+rm2J4yYxRSfEhiWqvNfiqLSUlsRfvEkYyU+16spgopuMHqkj gXCA== X-Forwarded-Encrypted: i=1; AJvYcCVOT+HiY0hxNI12TS4vNbVoTpacSJESn17ZeuTPYvxDiB8d2L/mWlUXaDCW377CP895+sRfNofFBSlE5wfBh2Xu7Nlrbiid3Lq3xPJAWQMaSQ== X-Gm-Message-State: AOJu0Yzthe77MD7TAIT9le0mbRXmyyyBpuU9q1a0HqBsHVPNZgQkQtXO vcz9Z0g28pqPM5PAMuEdmewDEXopXEKP3+mjn4oJqUyW4BGl3zOQ4QH6YsJYTEdoraUNatcrlql VRBjaroHoxAcmxwFOCk1Fv1pi9JiAppcvgIKB3w== X-Google-Smtp-Source: AGHT+IHwnSSVxbC0H4wOAfqTLir+RBHBgEwug0KrtQBEwxCe9SIULdeg8/iuJ9EF/mQBwBVwoV21jV84WLSTH0KCiuw= X-Received: by 2002:a17:90b:1183:b0:2c2:df58:bb8c with SMTP id 98e67ed59e1d1-2cff9430f46mr5103462a91.18.1722616538915; Fri, 02 Aug 2024 09:35:38 -0700 (PDT) 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: X-BeenThere: dev-commits-src-main@freebsd.org Sender: owner-dev-commits-src-main@FreeBSD.org MIME-Version: 1.0 References: <202408012131.471LVOGC039269@gitrepo.freebsd.org> In-Reply-To: From: Warner Losh Date: Fri, 2 Aug 2024 10:35:27 -0600 Message-ID: Subject: Re: git: 46ea2ffc3fbc - main - stand: Reduce limit to 500k for x86 loader To: Mark Johnston Cc: Warner Losh , src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Content-Type: multipart/alternative; boundary="000000000000e300dc061eb5eaa8" X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.99 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.989]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20230601.gappssmtp.com:s=20230601]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ARC_NA(0.00)[]; TO_DN_SOME(0.00)[]; MISSING_XM_UA(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::1032:from]; DMARC_NA(0.00)[bsdimp.com]; MLMMJ_DEST(0.00)[dev-commits-src-main@freebsd.org]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_FIVE(0.00)[5]; R_SPF_NA(0.00)[no SPF record]; PREVIOUSLY_DELIVERED(0.00)[dev-commits-src-main@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20230601.gappssmtp.com:+] X-Rspamd-Queue-Id: 4WbBKB0bj1z41H8 --000000000000e300dc061eb5eaa8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Aug 2, 2024 at 10:13=E2=80=AFAM Warner Losh wrote: > > > On Fri, Aug 2, 2024 at 8:29=E2=80=AFAM Mark Johnston = wrote: > >> On Thu, Aug 01, 2024 at 09:31:24PM +0000, Warner Losh wrote: >> > The branch main has been updated by imp: >> > >> > URL: >> https://cgit.FreeBSD.org/src/commit/?id=3D46ea2ffc3fbc42089d8322a65fdee8= 476d2b00d6 >> > >> > commit 46ea2ffc3fbc42089d8322a65fdee8476d2b00d6 >> > Author: Warner Losh >> > AuthorDate: 2024-08-01 21:24:51 +0000 >> > Commit: Warner Losh >> > CommitDate: 2024-08-01 21:30:26 +0000 >> > >> > stand: Reduce limit to 500k for x86 loader >> > >> > The largest loader that works for PXE boot is about 500k. PXE need= s >> low >> > memory for packets and other driver state, so the largest safe siz= e >> for >> > the loader is about 500k. Reduce the size from 560k to 500k so we >> don't >> > accidentally break PXE in the future. >> > >> > Add a comment for people with special needs. If you control the >> > hardware, it can be safe to have boot loaders as large as 580k or >> 600k >> > in some cases. Since the BIOS loader is becoming more and more of = a >> > legacy item, the build variable LOADERSIZE isn't documented. This >> change >> > doesn't change that: there's been little demand for this >> documentation >> > and in general, users shouldn't change it lightly. >> > >> > PR: 257018 >> > Sponsored by: Netflix >> > --- >> > stand/i386/loader/Makefile | 7 ++++++- >> > 1 file changed, 6 insertions(+), 1 deletion(-) >> > >> > diff --git a/stand/i386/loader/Makefile b/stand/i386/loader/Makefile >> > index a4aa3a3c4d45..efd442977780 100644 >> > --- a/stand/i386/loader/Makefile >> > +++ b/stand/i386/loader/Makefile >> > @@ -32,7 +32,12 @@ VERSION_FILE=3D ${.CURDIR}/../loader/version >> > # >> > # will tell you how many kiB of lomem are available. >> > # >> > -LOADERSIZE?=3D 560000 # Largest known safe size for loader.b= in >> > +# We further reduce this to 500k, though, to give PXE an additional >> 64k of space >> > +# so pxeloader will fit. If you have special needs that do not includ= e >> pxeboot, >> > +# you can safely set this as high as 560000 generally, or a bit highe= r >> if you >> > +# have tight control over the machines you are booting on. >> > +# >> > +LOADERSIZE?=3D 500000 # Largest known safe size for loader.b= in >> >> Hi Warner, >> >> This breaks the WITH_BEARSSL (which implies WITH_LOADER_VERIEXEC) build. >> When enabled, the loader ends up being just slightly larger than the >> limit. >> > > I sent another reply, but don't see it now. I hope it doesn't go out sinc= e > its tone was off. > > So for me, on main, this combination works. I'm able to build everything > with those two options. > One can't build with just WITH_LOADER_VERIEXEC, though, you need both. > Even if it had been > too big, one can fix this with LOADERSIZE=3D510000. Though doing that > automatically is tricky, > for reasons below. At the very least, I should make a note of it in the > WITH_xxx options. So are > there other options you are using, or maybe a different clang version tha= n > I have (which I think is > tip of main, but might be tip of may from early july). > > However, as the comment states: this is a special needs case. Veriexec > for BIOS is a fringe > activity compared to PXEBOOT using BIOS, so we have to draw some hard > lines in the default > settings. This is the first of the hard lines: The boot loader can't be > larger than 500k, at least until > we can get good data that larger sizes work with pxeboot. So this limit > isn't going to change until > there's new data that comes in, since there's way more pxeboot users. The > build breakage for > pxeboot is silent, and its users can be slow to resport it through the > right channels. So this > is the lessor evil: Strict limits and working pxeboot at the cost (evil) > that some people that add > in non-default options will need to do other special things. > > But what to do. Do we warn when these options are enabled? Do we bump the > size? Do we > disable pxeboot? Do we just do that if it's larger than a certain amount > (or fail so unless you've > disabled it, you'll see it's too big)? > > I'm inclined to (1) document you may need to bump LOADERSIZE with these > options and > (2) fail the pxeboot build if loader_lua is > 500,000 and maybe (3) have > a WITHOUT_LOADER_PXEBOOT > option as there isn't one already. That way, if you bump the size, you ma= y > have to also disable > pxeboot to have a successful build, but it will all be explicit and we'll > document that sometimes > too many options results in size issues that need careful testing after > overriding the safety limits. > > There's also a dark horse in this: There's a bug / pull request (I can't > recall which) that uses LTO > and other weird, but clever, tricks to reduce the size of the loader. > IIRC, it was a big win for loader.efi, > but much smaller win (or maybe even a slight pessimization) for > /boot/loader. I'll look into that to > see if any of the techniques used there can eke us out some space here. > https://reviews.freebsd.org/D46211 has what I had in mind for (1). It's really the only one of the three I'm not sure what to do about. Warner --000000000000e300dc061eb5eaa8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Aug 2, 2024 at 10:13=E2=80=AF= AM Warner Losh <imp@bsdimp.com>= wrote:


On Fri, Aug 2, 2024 at 8:29=E2=80=AFAM Mark J= ohnston <markj@fr= eebsd.org> wrote:
On Thu, Aug 01, 2024 at 09:31:24PM +0000, Warner Losh wrote:
> The branch main has been updated by imp:
>
> URL: https://= cgit.FreeBSD.org/src/commit/?id=3D46ea2ffc3fbc42089d8322a65fdee8476d2b00d6<= /a>
>
> commit 46ea2ffc3fbc42089d8322a65fdee8476d2b00d6
> Author:=C2=A0 =C2=A0 =C2=A0Warner Losh <imp@FreeBSD.org>
> AuthorDate: 2024-08-01 21:24:51 +0000
> Commit:=C2=A0 =C2=A0 =C2=A0Warner Losh <imp@FreeBSD.org>
> CommitDate: 2024-08-01 21:30:26 +0000
>
>=C2=A0 =C2=A0 =C2=A0stand: Reduce limit to 500k for x86 loader
>=C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0The largest loader that works for PXE boot is about= 500k. PXE needs low
>=C2=A0 =C2=A0 =C2=A0memory for packets and other driver state, so the l= argest safe size for
>=C2=A0 =C2=A0 =C2=A0the loader is about 500k. Reduce the size from 560k= to 500k so we don't
>=C2=A0 =C2=A0 =C2=A0accidentally break PXE in the future.
>=C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0Add a comment for people with special needs. If you= control the
>=C2=A0 =C2=A0 =C2=A0hardware, it can be safe to have boot loaders as la= rge as 580k or 600k
>=C2=A0 =C2=A0 =C2=A0in some cases. Since the BIOS loader is becoming mo= re and more of a
>=C2=A0 =C2=A0 =C2=A0legacy item, the build variable LOADERSIZE isn'= t documented. This change
>=C2=A0 =C2=A0 =C2=A0doesn't change that: there's been little de= mand for this documentation
>=C2=A0 =C2=A0 =C2=A0and in general, users shouldn't change it light= ly.
>=C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0PR: 257018
>=C2=A0 =C2=A0 =C2=A0Sponsored by: Netflix
> ---
>=C2=A0 stand/i386/loader/Makefile | 7 ++++++-
>=C2=A0 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/stand/i386/loader/Makefile b/stand/i386/loader/Makefile > index a4aa3a3c4d45..efd442977780 100644
> --- a/stand/i386/loader/Makefile
> +++ b/stand/i386/loader/Makefile
> @@ -32,7 +32,12 @@ VERSION_FILE=3D=C2=A0 =C2=A0 =C2=A0 ${.CURDIR}/../l= oader/version
>=C2=A0 #
>=C2=A0 # will tell you how many kiB of lomem are available.
>=C2=A0 #
> -LOADERSIZE?=3D 560000=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 # Largest kno= wn safe size for loader.bin
> +# We further reduce this to 500k, though, to give PXE an additional 6= 4k of space
> +# so pxeloader will fit. If you have special needs that do not includ= e pxeboot,
> +# you can safely set this as high as 560000 generally, or a bit highe= r if you
> +# have tight control over the machines you are booting on.
> +#
> +LOADERSIZE?=3D 500000=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 # Largest kno= wn safe size for loader.bin

Hi Warner,

This breaks the WITH_BEARSSL (which implies WITH_LOADER_VERIEXEC) build. When enabled, the loader ends up being just slightly larger than the
limit.

<= div>
One can't build = with just WITH_LOADER_VERIEXEC, though, you need both. Even if it had been<= /div>
too big, one can fix this with LOADERSIZE=3D510000. Though doing = that automatically is tricky,
for reasons below. At the very leas= t, I should make a note of it in the WITH_xxx options. So are
the= re other options you are using, or maybe a different clang version than I h= ave (which I think is
tip of main, but might be tip of may from e= arly july).

However, as=C2=A0 the comment states: = this is a special needs case. Veriexec for BIOS is a fringe
activ= ity compared to PXEBOOT=C2=A0using BIOS, so we have to draw some hard lines= in the default
settings. This is the first of the hard lines: Th= e boot loader can't be larger than 500k, at least until
we ca= n get good data that larger sizes work with pxeboot. So this limit isn'= t going to change until
there's new data that comes in, since= there's way more pxeboot=C2=A0users. The build breakage for
= pxeboot=C2=A0is silent, and its users can be slow to resport=C2=A0it throug= h the right channels. So this
is the lessor evil: Strict limits a= nd working pxeboot=C2=A0at the cost (evil) that some people that add
<= div>in non-default options will need to do other special things.
disabled it, you'll see it's too big)?



<= div>https://reviews.freebsd.= org/D46211 has what I had in mind for (1). It's really the only one= of the three
I'm not sure what to do about.

Warner=C2=A0
--000000000000e300dc061eb5eaa8--