Date: Thu, 11 Aug 2022 13:36:57 -0600 From: Warner Losh <imp@bsdimp.com> To: Cy Schubert <Cy.Schubert@cschubert.com> Cc: John Baldwin <jhb@freebsd.org>, Warner Losh <imp@freebsd.org>, src-committers <src-committers@freebsd.org>, "<dev-commits-src-all@freebsd.org>" <dev-commits-src-all@freebsd.org>, 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: <CANCZdfp0Rg3gx_dwVjbTrwzLeYyZAjHP3wAsxt5Vvw541VVF2Q@mail.gmail.com> In-Reply-To: <20220811192600.9F0B4119@slippy.cwsent.com> References: <202208110331.27B3Va7M007335@gitrepo.freebsd.org> <727af1f3-7432-c038-a776-682ef161f6f9@FreeBSD.org> <20220811192600.9F0B4119@slippy.cwsent.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--00000000000081d69a05e5fc4a36 Content-Type: text/plain; charset="UTF-8" On Thu, Aug 11, 2022 at 1:26 PM Cy Schubert <Cy.Schubert@cschubert.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=39fdad34e220c52a433e78f20c8c39 > > 412429014e > > > > > > commit 39fdad34e220c52a433e78f20c8c39412429014e > > > Author: Warner Losh <imp@FreeBSD.org> > > > AuthorDate: 2022-08-11 03:19:01 +0000 > > > Commit: Warner Losh <imp@FreeBSD.org> > > > 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 <div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">= <div dir=3D"ltr" class=3D"gmail_attr">On Thu, Aug 11, 2022 at 1:26 PM Cy Sc= hubert <<a href=3D"mailto:Cy.Schubert@cschubert.com">Cy.Schubert@cschube= rt.com</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"m= argin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left= :1ex">In message <727af1f3-7432-c038-a776-682ef161f6f9@FreeBSD.org>, = John Baldwin <br> wri<br> tes:<br> > On 8/10/22 8:31 PM, Warner Losh wrote:<br> > > The branch main has been updated by imp:<br> > > <br> > > URL: <a href=3D"https://cgit.FreeBSD.org/src/commit/?id=3D39fdad3= 4e220c52a433e78f20c8c39" rel=3D"noreferrer" target=3D"_blank">https://cgit.= FreeBSD.org/src/commit/?id=3D39fdad34e220c52a433e78f20c8c39</a><br> > 412429014e<br> > > <br> > > commit 39fdad34e220c52a433e78f20c8c39412429014e<br> > > Author:=C2=A0 =C2=A0 =C2=A0Warner Losh <imp@FreeBSD.org><br= > > > AuthorDate: 2022-08-11 03:19:01 +0000<br> > > Commit:=C2=A0 =C2=A0 =C2=A0Warner Losh <imp@FreeBSD.org><br= > > > CommitDate: 2022-08-11 03:29:20 +0000<br> > > <br> > >=C2=A0 =C2=A0 =C2=A0 stand: impose 510,000 byte limit for /boot/lo= ader and /boot/pxeldr<br> > >=C2=A0 =C2=A0 =C2=A0 <br> > >=C2=A0 =C2=A0 =C2=A0 The BIOS method of booting imposes an absolut= e limit of 640k for the<br> > >=C2=A0 =C2=A0 =C2=A0 size of the program being run due to btx. In = practice, this means that<br> > >=C2=A0 =C2=A0 =C2=A0 programs larger than about 500kiB will fail i= n odd ways as the stack /<br> > >=C2=A0 =C2=A0 =C2=A0 heap will overflow.<br> ><br> > Technically the heap is now always above 1MB, the issue is the stack g= rowing<br> > down and overwriting .bss.<br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 <br> > >=C2=A0 =C2=A0 =C2=A0 Pick 510,000 as the cutoff line semi-arbitrar= ily. loader_lua is now<br> > >=C2=A0 =C2=A0 =C2=A0 almost too big and we want to break the build= when it crosses this<br> > >=C2=A0 =C2=A0 =C2=A0 threshold. In my experience, below 500,000 al= ways works, above 520,000<br> > >=C2=A0 =C2=A0 =C2=A0 always seems to fail with things getting bad = somewhere between 512,000<br> > >=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<br> > gh<br> > >=C2=A0 =C2=A0 =C2=A0 experience may dictate we need to lower this = in the future.<br> > >=C2=A0 =C2=A0 =C2=A0 <br> > >=C2=A0 =C2=A0 =C2=A0 This is at-best a stop-breakage until we have= a better way to subset t<br> > he<br> > >=C2=A0 =C2=A0 =C2=A0 boot loader for BIOS booting to allow better,= more fined-tuned<br> > >=C2=A0 =C2=A0 =C2=A0 /boot/loaders for the many different environm= ents they have to run<br> > >=C2=A0 =C2=A0 =C2=A0 in. This likely means we'll have a graphi= cal loader than understands a<br> > >=C2=A0 =C2=A0 =C2=A0 few filesystmes for installation, and a non-g= raphical loader that<br> > >=C2=A0 =C2=A0 =C2=A0 understands the most filesystems possible for= everything else in the<br> > >=C2=A0 =C2=A0 =C2=A0 future. Our build infrastructure needs some w= ork before we can do that<br> > ,<br> > >=C2=A0 =C2=A0 =C2=A0 however.<br> > >=C2=A0 =C2=A0 =C2=A0 <br> > >=C2=A0 =C2=A0 =C2=A0 At this late date, it likely isn't worth = the efforts to move parts of<br> > >=C2=A0 =C2=A0 =C2=A0 the loader into high memory. There's a nu= mber of assumptions about whe<br> > re<br> > >=C2=A0 =C2=A0 =C2=A0 the stack is, where buffers reside, etc that = are fulfilled when it liv<br> > es<br> > >=C2=A0 =C2=A0 =C2=A0 in the first 640k that would need bounce buff= ers and/or other counter<br> > >=C2=A0 =C2=A0 =C2=A0 measures if we were to split it up. All BIOS = calls are done in 16-bit<br> > >=C2=A0 =C2=A0 =C2=A0 mode with SEG:OFF addresses, requiring them t= o be in the first 640k of<br> > >=C2=A0 =C2=A0 =C2=A0 RAM. And nearly all machines in the last deca= de can boot with UEFI<br> > >=C2=A0 =C2=A0 =C2=A0 (though there's some exceptions, so it is= n't worth killing outright<br> > >=C2=A0 =C2=A0 =C2=A0 yet).<br> ><br> > Fully agree that we just want to keep the BIOS loader on a sufficient = feature<br> > diet.<br> <br> Agreed. Those with a significant investment in hardware needing upgrade <br= > might need sufficient heads up so that they can budget for replacements <br= > over time.<br></blockquote><div><br></div><div>Yes. We have to remove the n= ice to have, but optional, bits from the BIOS loader to</div><div>give us b= reathing room for other features.</div><div><br></div><div>Warner</div></di= v></div> --00000000000081d69a05e5fc4a36--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfp0Rg3gx_dwVjbTrwzLeYyZAjHP3wAsxt5Vvw541VVF2Q>