Re: git: 39fdad34e220 - main - stand: impose 510,000 byte limit for /boot/loader and /boot/pxeldr

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.


-- 
Cheers,
Cy Schubert <Cy.Schubert@cschubert.com>
FreeBSD UNIX:  <cy@FreeBSD.org>   Web:  http://www.FreeBSD.org
NTP:           <cy@nwtime.org>    Web:  https://nwtime.org

			e**(i*pi)+1=0