From nobody Fri Aug 02 16:13:51 2024 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 4Wb9rD3ZvBz5RyqZ for ; Fri, 02 Aug 2024 16:14:04 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pj1-x102e.google.com (mail-pj1-x102e.google.com [IPv6:2607:f8b0:4864:20::102e]) (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 4Wb9rD1hq6z3xJ0 for ; Fri, 2 Aug 2024 16:14:04 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pj1-x102e.google.com with SMTP id 98e67ed59e1d1-2cf11b91813so5725995a91.1 for ; Fri, 02 Aug 2024 09:14:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1722615243; x=1723220043; 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=q5Qld84aGfJI1IdBeobxMrYKdXCXPi/LSpxxcIzxNvc=; b=Oh1A5JjbiW7TWNSYJ1EVIjISAfi9jGJwgjYCT7U5M6pgpVeIr1mlGS64WEmi0n8A5h W2UoczEa34PRBB/xxlGyFPJMfZ4EkYGQeMBK1J1ZaNgNMvzCb6dDLEEsrOSD/r3oR/x2 5WIUAsX7vACxLlBrFnuT0jHPEfk6ywmtv8AegS23Zo0WuCMAay1yHeyKlFHrNrdrf/nD L3AK9BbGE9dNmFgQu+HNkgmjoGX4/ueMLiWPSOPzOnEl6mnA7DDYRYM3q53ttwa/tNuK GT/Lj5+CgW14sLjjL99Nmah7wvW6hWzgAvYJj23yse8QJvGxiLZsLXT5TUCFZmwUvhYu jKcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722615243; x=1723220043; 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=q5Qld84aGfJI1IdBeobxMrYKdXCXPi/LSpxxcIzxNvc=; b=NZmqqijQB5BQx+BhvQMkX2EIrmPlcVmzRwUFFkLGKyFVXaRf5r4JDXyHtKNkFwTXhe kRnPsJycbn5TuEOoH3FUYKcMVnBwmY6cf5jLEByasJXmyFB9pa3YAm5xgpl82BRjTZDn +jkdhTDV3JXKhlYqr30HYytGc8jRR0tpNbrHLccqBW4XIl7D5HXmoSSIln4zDhIlbUvB dy/fWQQVXDacbESmG483pOfKVihhRDUvqojp7XDnhOpSqhzkagk5V6ebZWoc+BkS7B4y ozVW7faMdunHZtdGaYFBKhESabKznBb1ccko61T1WI3l2SLfycTpjz6mV/9DadkI79Ep WGHA== X-Forwarded-Encrypted: i=1; AJvYcCUr2uq1G65gV7UivuylEzTDpXiNAuuY0d0x293aSFTay39uVgM3yQalckbM6J1Djl/5YRXJgZfkWvlWR2b3OU3inEyvQuXlzLGTKBypJ7hR X-Gm-Message-State: AOJu0YwmwpJpe+OrkadULHj57LgTk1IlZJRy9ReD2OJdbzoH0X8a8Yun 1x5G6GGw+2yg36jApbqB7STc5P1YfE9ALRdxsULjigU+yipFZOpYOJRsmCjgiRbg4oauCYLyckW N4g/8m5tKE/rm4JDoAucwEbT4tPmlqcxPFFrMZA== X-Google-Smtp-Source: AGHT+IF1+Og+iG/qXlN4wL+LABixxsCvJOo8Zy3x20ndIn4SUJnRozTQCE6PFncPI1eHOghIctwjQuLVO0U0mMZueSo= X-Received: by 2002:a17:90a:644b:b0:2c9:6514:39ff with SMTP id 98e67ed59e1d1-2cff952c35bmr4966114a91.33.1722615242596; Fri, 02 Aug 2024 09:14:02 -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: X-BeenThere: dev-commits-src-all@freebsd.org Sender: owner-dev-commits-src-all@FreeBSD.org MIME-Version: 1.0 References: <202408012131.471LVOGC039269@gitrepo.freebsd.org> In-Reply-To: From: Warner Losh Date: Fri, 2 Aug 2024 10:13:51 -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="0000000000009ec51f061eb59dd1" X-Spamd-Bar: ---- 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)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4Wb9rD1hq6z3xJ0 --0000000000009ec51f061eb59dd1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Aug 2, 2024 at 8:29=E2=80=AFAM Mark Johnston wr= ote: > 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=3D46ea2ffc3fbc42089d8322a65fdee84= 76d2b00d6 > > > > 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 needs > low > > memory for packets and other driver state, so the largest safe size > 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.bi= n > > +# We further reduce this to 500k, though, to give PXE an additional 64= k > of space > > +# so pxeloader will fit. If you have special needs that do not include > pxeboot, > > +# you can safely set this as high as 560000 generally, or a bit higher > if you > > +# have tight control over the machines you are booting on. > > +# > > +LOADERSIZE?=3D 500000 # Largest known safe size for loader.bi= n > > 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 since 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 than 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 may 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. Warner --0000000000009ec51f061eb59dd1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Aug 2, 2024 at 8:29=E2=80=AFA= M Mark Johnston <markj@freebsd.org<= /a>> wrote:
O= n 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)?



--0000000000009ec51f061eb59dd1--