From nobody Thu Aug 11 19:36:57 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 4M3cWn05vxz4YXbC for ; Thu, 11 Aug 2022 19:37:09 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vk1-xa2a.google.com (mail-vk1-xa2a.google.com [IPv6:2607:f8b0:4864:20::a2a]) (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 4M3cWm6r9Cz3HG4 for ; Thu, 11 Aug 2022 19:37:08 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vk1-xa2a.google.com with SMTP id q191so9428599vkb.6 for ; Thu, 11 Aug 2022 12:37:08 -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=AsFHGb/0MEx3JJX1+TBCLNV1UnYHEU8h9kBhYXD205Q=; b=KS2L1itkJErBi5Amr1cW3MV0dV3jNH42Sk7J4TOA++0TY+bKClDlYZXOnNIoWGQAvu g0HSNbf+s1yDSDPsI1W0p3TVU/kz+7jpDXZ+R1+603mmkL3kxq766eoA3k7MIXIE/494 /8Wtp0cKPRoP2jWY5Ek1M+gGpG1YMcbGUB8fgsnEMz6QEAHvdOt6Y/AieS3TmsTVD70x KfmCy2Wkqb5tReYZVMNyCVhyv9xPVX0rzW2L21oRK3MG05jDjKIAJgrjJDDtzFfXEpc7 ny9xAqMWg8v/E90pXn0jU2qWUwFleSKEPww30qO3NHacyAlZx3CKbj5N/BxwnsYsPQv6 GaBA== 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=AsFHGb/0MEx3JJX1+TBCLNV1UnYHEU8h9kBhYXD205Q=; b=Fy3efKDfWvujqLykieyZ6s1k1ORjdMnqcqlJqhQvVSTiTsBIEDHi2rk0VpeSdm2Wmf i2FvXCsojMg5vGMpbcg8E79tNFLVjs6G/38XuBc3DcLnwYl3LQZGH9pvrVaI2NHWwZr1 EKRRlO2YmlhmmyPC/5TeN1OXRwypC1G6W4S4SgsU/OUQi1BdqsPNnA8IYJjLXc21h3A9 GfWkvzMIKU5wKKPV/z/0NehBQ1U9+z7lNtx6QfB1Eg35nkvASKbE5thC12B2fuLfOCac qZCAZwIFSN9OONRitnlHKsWcVfremG7sVLhsRDY6bxth72AYW20n3c5oKhFusujaSjQ3 X6Ig== X-Gm-Message-State: ACgBeo0p13ONn9ryuhhYFABoZPOZDDAdz5zGmzCYRmCao/VCIv8KZ8lF z75mhOUI++eH6sjfOAq2iMFBIKfZxRIw8LXXOTrEEpWtvP0= X-Google-Smtp-Source: AA6agR4DhFdL5J9yao3fqXnvO4jcEC6OV0KdTY2UzU9AI47UldWLlqq+8h2cDRsk0Lq8TgDqPeAsiOHU7NNL6Cjw3Ek= X-Received: by 2002:a1f:3803:0:b0:378:bd6f:249d with SMTP id f3-20020a1f3803000000b00378bd6f249dmr319673vka.13.1660246628089; Thu, 11 Aug 2022 12:37:08 -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: Sender: owner-dev-commits-src-main@freebsd.org X-BeenThere: dev-commits-src-main@freebsd.org MIME-Version: 1.0 References: <202208110331.27B3Va7M007335@gitrepo.freebsd.org> <727af1f3-7432-c038-a776-682ef161f6f9@FreeBSD.org> <20220811192600.9F0B4119@slippy.cwsent.com> In-Reply-To: <20220811192600.9F0B4119@slippy.cwsent.com> From: Warner Losh Date: Thu, 11 Aug 2022 13:36:57 -0600 Message-ID: Subject: Re: git: 39fdad34e220 - main - stand: impose 510,000 byte limit for /boot/loader and /boot/pxeldr To: Cy Schubert Cc: John Baldwin , Warner Losh , src-committers , "" , dev-commits-src-main@freebsd.org Content-Type: multipart/alternative; boundary="00000000000081d69a05e5fc4a36" X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Rspamd-Queue-Id: 4M3cWm6r9Cz3HG4 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 --00000000000081d69a05e5fc4a36 Content-Type: text/plain; charset="UTF-8" On Thu, Aug 11, 2022 at 1:26 PM Cy Schubert wrote: > In message <727af1f3-7432-c038-a776-682ef161f6f9@FreeBSD.org>, John > Baldwin > wri > tes: > > On 8/10/22 8:31 PM, Warner Losh wrote: > > > The branch main has been updated by imp: > > > > > > URL: > https://cgit.FreeBSD.org/src/commit/?id=39fdad34e220c52a433e78f20c8c39 > > 412429014e > > > > > > 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. > > > > Technically the heap is now always above 1MB, the issue is the stack > growing > > down and overwriting .bss. > > > > > 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, > thou > > gh > > > 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 t > > he > > > 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 whe > > re > > > the stack is, where buffers reside, etc that are fulfilled when > it liv > > es > > > 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). > > > > Fully agree that we just want to keep the BIOS loader on a sufficient > feature > > diet. > > Agreed. Those with a significant investment in hardware needing upgrade > might need sufficient heads up so that they can budget for replacements > over time. > Yes. We have to remove the nice to have, but optional, bits from the BIOS loader to give us breathing room for other features. Warner --00000000000081d69a05e5fc4a36 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Aug 11, 2022 at 1:26 PM Cy Sc= hubert <Cy.Schubert@cschube= rt.com> wrote:
In message <727af1f3-7432-c038-a776-682ef161f6f9@FreeBSD.org>, = John Baldwin
wri
tes:
> On 8/10/22 8:31 PM, Warner Losh wrote:
> > The branch main has been updated by imp:
> >
> > URL: https://cgit.= FreeBSD.org/src/commit/?id=3D39fdad34e220c52a433e78f20c8c39
> 412429014e
> >
> > 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=A0 stand: impose 510,000 byte limit for /boot/lo= ader and /boot/pxeldr
> >=C2=A0 =C2=A0 =C2=A0
> >=C2=A0 =C2=A0 =C2=A0 The BIOS method of booting imposes an absolut= e limit of 640k for the
> >=C2=A0 =C2=A0 =C2=A0 size of the program being run due to btx. In = practice, this means that
> >=C2=A0 =C2=A0 =C2=A0 programs larger than about 500kiB will fail i= n odd ways as the stack /
> >=C2=A0 =C2=A0 =C2=A0 heap will overflow.
>
> Technically the heap is now always above 1MB, the issue is the stack g= rowing
> down and overwriting .bss.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0
> >=C2=A0 =C2=A0 =C2=A0 Pick 510,000 as the cutoff line semi-arbitrar= ily. loader_lua is now
> >=C2=A0 =C2=A0 =C2=A0 almost too big and we want to break the build= when it crosses this
> >=C2=A0 =C2=A0 =C2=A0 threshold. In my experience, below 500,000 al= ways works, above 520,000
> >=C2=A0 =C2=A0 =C2=A0 always seems to fail with things getting bad = somewhere between 512,000
> >=C2=A0 =C2=A0 =C2=A0 to 515,000. 510,000 is as close to the line a= s I think we can go, thou
> gh
> >=C2=A0 =C2=A0 =C2=A0 experience may dictate we need to lower this = in the future.
> >=C2=A0 =C2=A0 =C2=A0
> >=C2=A0 =C2=A0 =C2=A0 This is at-best a stop-breakage until we have= a better way to subset t
> he
> >=C2=A0 =C2=A0 =C2=A0 boot loader for BIOS booting to allow better,= more fined-tuned
> >=C2=A0 =C2=A0 =C2=A0 /boot/loaders for the many different environm= ents they have to run
> >=C2=A0 =C2=A0 =C2=A0 in. This likely means we'll have a graphi= cal loader than understands a
> >=C2=A0 =C2=A0 =C2=A0 few filesystmes for installation, and a non-g= raphical loader that
> >=C2=A0 =C2=A0 =C2=A0 understands the most filesystems possible for= everything else in the
> >=C2=A0 =C2=A0 =C2=A0 future. Our build infrastructure needs some w= ork before we can do that
> ,
> >=C2=A0 =C2=A0 =C2=A0 however.
> >=C2=A0 =C2=A0 =C2=A0
> >=C2=A0 =C2=A0 =C2=A0 At this late date, it likely isn't worth = the efforts to move parts of
> >=C2=A0 =C2=A0 =C2=A0 the loader into high memory. There's a nu= mber of assumptions about whe
> re
> >=C2=A0 =C2=A0 =C2=A0 the stack is, where buffers reside, etc that = are fulfilled when it liv
> es
> >=C2=A0 =C2=A0 =C2=A0 in the first 640k that would need bounce buff= ers and/or other counter
> >=C2=A0 =C2=A0 =C2=A0 measures if we were to split it up. All BIOS = calls are done in 16-bit
> >=C2=A0 =C2=A0 =C2=A0 mode with SEG:OFF addresses, requiring them t= o be in the first 640k of
> >=C2=A0 =C2=A0 =C2=A0 RAM. And nearly all machines in the last deca= de can boot with UEFI
> >=C2=A0 =C2=A0 =C2=A0 (though there's some exceptions, so it is= n't worth killing outright
> >=C2=A0 =C2=A0 =C2=A0 yet).
>
> Fully agree that we just want to keep the BIOS loader on a sufficient = feature
> diet.

Agreed. Those with a significant investment in hardware needing upgrade might need sufficient heads up so that they can budget for replacements over time.

Yes. We have to remove the n= ice to have, but optional, bits from the BIOS loader to
give us b= reathing room for other features.

Warner
--00000000000081d69a05e5fc4a36--