On 8/11/22 11:18 AM, Warner Losh wrote:
On Thu, Aug 11, 2022 at 10:56 AM John Baldwin <j...@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.
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.
--
John Baldwin
