Date: Thu, 11 Aug 2022 18:44:07 -0600 From: Warner Losh <imp@bsdimp.com> To: John Baldwin <jhb@freebsd.org> Cc: 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: <CANCZdfpxXvTabA5jGSv9mucjECw0uEzmsK0R9SdgV14FHO=oxQ@mail.gmail.com> In-Reply-To: <ad8467cd-bbc7-37cf-b085-72bf34256431@FreeBSD.org> References: <202208110331.27B3Va7M007335@gitrepo.freebsd.org> <727af1f3-7432-c038-a776-682ef161f6f9@FreeBSD.org> <CANCZdfo-CyHD0jj==14Cimy9g77MqEBjZV1ho=TC7qgoDz6eCg@mail.gmail.com> <ad8467cd-bbc7-37cf-b085-72bf34256431@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--0000000000001b0ffa05e60095a4 Content-Type: text/plain; charset="UTF-8" On Thu, Aug 11, 2022, 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. > > 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. > I ran into problems with a simple system... with lots of disks (10) visible to the BIOS. And that was at 518kB. Just UFS. GZIP and BZIP2 were configured bur not active. Warner -- > John Baldwin > --0000000000001b0ffa05e60095a4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"auto"><div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr" = class=3D"gmail_attr">On Thu, Aug 11, 2022, 6:24 PM John Baldwin <<a href= =3D"mailto:jhb@freebsd.org">jhb@freebsd.org</a>> wrote:<br></div><blockq= uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc = solid;padding-left:1ex">On 8/11/22 11:18 AM, Warner Losh wrote:<br> > On Thu, Aug 11, 2022 at 10:56 AM John Baldwin <<a href=3D"mailto:jh= b@freebsd.org" target=3D"_blank" rel=3D"noreferrer">jhb@freebsd.org</a>>= wrote:<br> >> You really want to apply the size check to loader.bin, not loader.= =C2=A0 The<br> >> memory<br> >> layout down in the first 1MB for boot loaders is roughly:<br> >><br> >> 0x0000: real-mode IDT<br> >> 0x0400: BIOS data<br> >> 0x7c00: where BIOS loads boot loaders such as /boot/mbr, etc.<br> >> 0x1000: various BTX global data like GDT, TSS, IDT, stacks<br> >> 0x9000: BTX kernel<br> >> 0xa000: BTX client (loader.bin)<br> >> 0xa0000: top of BTX client stack (though this can be a bit lower f= or cases<br> >> like<br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 PXE booting)<br> >><br> >> The real size constraint is on the BTX client (loader.bin) and the= fact<br> >> that<br> >> it's text/data/bss plus stack need to fit into that 576k windo= w (give or<br> >> take).<br> >> btxldr isn't stored in low memory, so its size isn't relev= ant, and BTX's<br> >> code<br> >> always takes up a full page even though it is much smaller.<br> >><br> > <br> > Where does 576k come from? That's 589824 bytes, but a0000-a000 is = 614400<br> > bytes. The delta is 24k (24576). My 'observed' value of about = 515,000 is<br> > another<br> > 75k below that, suggesting we are needing 100k of stack? Can that be r= ight?<br> > I knew<br> > lua ate a lot of stack, but wow!<br> <br> Hmm, I converted 0xa000 to 64k instead of 40k in my head which is where<br> the 576k came from.=C2=A0 Yeah, the total size is 600k.=C2=A0 100k stack do= es seem<br> like a lot.=C2=A0 It is possible that other BIOS ROMs besides just PXE migh= t<br> steal data from the stack top.=C2=A0 You could maybe try looking at some of= <br> your existing BIOS-boot machines to check the 16-bit word at physical<br> address 0x413.=C2=A0 That gives you the actual top of the 640k window.=C2= =A0 On<br> my current desktop (albeit booted via UEFI and not BIOS) it is 629k:<br> <br> % sudo dd if=3D/dev/mem bs=3D1 iseek=3D0x413 count=3D2 | hd<br> 2+0 records in<br> 2+0 records out<br> 2 bytes transferred in 0.000026 secs (75643 bytes/sec)<br> 00000000=C2=A0 75 02=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|u.|<br> 00000002<br> % gdb<br> ...<br> (gdb) p/d 0x275<br> $2 =3D 629<br> <br> Still, that's only 11k gone.<br> <br> I do think that when people have ran into trouble in the past it has been<b= r> in situations that can recurse, e.g. using psuedo-filesystems like gzipfs<b= r> where the gzipfs open routine tries to open the underlying "foo.gz&quo= t; file,<br> etc.<br></blockquote></div></div><div dir=3D"auto"><br></div><div dir=3D"au= to">I ran into problems with a simple system... with lots of disks (10) vis= ible to the BIOS. And that was at 518kB. Just UFS. GZIP and BZIP2 were conf= igured bur not active.</div><div dir=3D"auto"><br></div><div dir=3D"auto">W= arner</div><div dir=3D"auto"><br></div><div dir=3D"auto"><div class=3D"gmai= l_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde= r-left:1px #ccc solid;padding-left:1ex"> -- <br> John Baldwin<br> </blockquote></div></div></div> --0000000000001b0ffa05e60095a4--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfpxXvTabA5jGSv9mucjECw0uEzmsK0R9SdgV14FHO=oxQ>