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

On Thu, Aug 11, 2022 at 6:24 PM John Baldwin <jhb@freebsd.org> wrote:

> On 8/11/22 11:18 AM, Warner Losh wrote:
> > On Thu, Aug 11, 2022 at 10:56 AM John Baldwin <jhb@freebsd.org> wrote:
> >> You really want to apply the size check to loader.bin, not loader.  The
> >> memory
> >> layout down in the first 1MB for boot loaders is roughly:
> >>
> >> 0x0000: real-mode IDT
> >> 0x0400: BIOS data
> >> 0x7c00: where BIOS loads boot loaders such as /boot/mbr, etc.
> >> 0x1000: various BTX global data like GDT, TSS, IDT, stacks
> >> 0x9000: BTX kernel
> >> 0xa000: BTX client (loader.bin)
> >> 0xa0000: top of BTX client stack (though this can be a bit lower for
> cases
> >> like
> >>            PXE booting)
> >>
> >> The real size constraint is on the BTX client (loader.bin) and the fact
> >> that
> >> it's text/data/bss plus stack need to fit into that 576k window (give or
> >> take).
> >> btxldr isn't stored in low memory, so its size isn't relevant, and BTX's
> >> code
> >> always takes up a full page even though it is much smaller.
> >>
> >
> > Where does 576k come from? That's 589824 bytes, but a0000-a000 is 614400
> > bytes. The delta is 24k (24576). My 'observed' value of about 515,000 is
> > another
> > 75k below that, suggesting we are needing 100k of stack? Can that be
> right?
> > I knew
> > lua ate a lot of stack, but wow!
>
> Hmm, I converted 0xa000 to 64k instead of 40k in my head which is where
> the 576k came from.  Yeah, the total size is 600k.  100k stack does seem
> like a lot.  It is possible that other BIOS ROMs besides just PXE might
> steal data from the stack top.  You could maybe try looking at some of
> your existing BIOS-boot machines to check the 16-bit word at physical
> address 0x413.  That gives you the actual top of the 640k window.  On
> my current desktop (albeit booted via UEFI and not BIOS) it is 629k:
>
> % sudo dd if=/dev/mem bs=1 iseek=0x413 count=2 | hd
> 2+0 records in
> 2+0 records out
> 2 bytes transferred in 0.000026 secs (75643 bytes/sec)
> 00000000  75 02                                             |u.|
> 00000002
> % gdb
> ...
> (gdb) p/d 0x275
> $2 = 629
> Still, that's only 11k gone.
>

So on the machine that I'm having issues with...

# dd if=/dev/mem bs=1 iseek=0x413 count=2 | hd
00000000  37 02
# echo  $((0x237))
567

Super Yikes!

I do think that when people have ran into trouble in the past it has been
> in situations that can recurse, e.g. using psuedo-filesystems like gzipfs
> where the gzipfs open routine tries to open the underlying "foo.gz" file,
> etc.
>

Yea, I'm having trouble because I'm missing 73k of stack...

Warner


> --
> John Baldwin
>