[syslinux] Proposal for Chain-Loadable LDLINUX.SYS

Shao Miller sha0.miller at gmail.com
Wed Dec 5 16:38:49 PST 2012


A proposal for changing the LDLINUX.SYS layout and flow:

The current situation ("old style"):

   ldlinux.bin's physical layout:
   - VBR
   - 512 bytes of padding (never lands in memory)
   - ldlinux.sys, which is:
     - Sect1 code (494 bytes, leaving enough room for at least one 
extent, as planned)
     - Extent pointer patch space (1920 bytes)
     - The rest of the code

   ldlinux.bin's in-memory layout:
   - VBR @ 0:7C00 (or wherever else a crazy BIOS might put it)
   - ldlinux.sys @ 0:8000
     - Sect1 code @ 0:8000
     - Extent pointers @ 0:81EE
     - The rest of the code @ 0:896E

Proposal for a future style:

   ldlinux.bin == ldlinux.sys

   ldlinux.sys' physical layout:
   - Sect1 code
   - Extent pointer patch space
   - The rest of the old-style ldlinux.sys code
   - 1024 bytes of Special Padding (you'll see why, later)
   - New Special Code
   - Padding to a 512-byte boundary
   - VBR

   ldlinux.sys' in-memory layout (unchanged from old style):
   - VBR @ 0:7C00 (or wherever else a crazy BIOS might put it)
   - ldlinux.sys @ 0:8000
     - Sect1 code @ 0:8000
     - Extent pointers @ 0:81EE
     - The rest of the code @ 0:896E

The goals are:

   - That the installers wouldn't carry the VBR around as a separate 
blob, but could extract it from the end of the embedded ldlinux.sys, 
instead.

   - Sect1 could check to see where the instruction pointer is.  If it 
is near 0:7C00, then some other boot-loader has loaded the whole 
ldlinux.sys there.  Because the whole file is loaded, jump to New 
Special Code.  If it is near 0:8000, then this is the usual load from 
the VBR; carry on as usual (no more discussion about the usual case).

   - New Special Code only runs when the whole ldlinux.sys has been 
loaded into memory.  It shuffles down everything _before_ Special 
Padding from 0:7C00 (where some other boot-loader loaded all of 
ldlinux.sys) down to 0:8000 (where it's usually loaded by the VBR).

   - Now Special Padding has been obliterated and New Special Code 
immediately follows the rest of the old-style ldlinux.sys code (not that 
it really matters, as long as New Special Code is not overwritten)

   - New Special Code reads _the_actual_ disk VBR to 0:7C00, since 
everything's been shuffled down

   - New Special Code patches 0:7C00 with the ldlinux.sys VBR code, 
leaving the FS data intact.  It then patches the VBR code to skip 
loading Sect1 from disk.  It also patches Sect1 to skip loading the rest 
of ldlinux.sys from disk.  (Sectors to load == 0)

   - New Special Code then jumps into the VBR code.

   - VBR code then does what it does except for loading Sect1, but still 
jumps to it.

   - Sect1 then does what it does except for loading the rest of 
ldlinux.sys from disk.

   - The rest of ldlinux.sys executes

Does this make any sense as a possible way to chain-load ldlinux.sys 
from another boot-loader, without much risk of interfering with the 
current and common loaded-from-VBR flow?

If my design makes sense, the only space needed from currently existing 
blobs would be for the new "check and possibly jump if we're at 0:7C00", 
in Sect1.

The installers would obviously need to deal with a change in the layout 
of ldlinux.sys/ldlinux.bin

I don't know if NASM allows for the VBR (which will live at 0:7C00) to 
come, in the binary file, physically after the usual ldlinux.sys code at 
0:8000.

I think a big win for this is that users don't need the installers for 
this...  Wherever they happen to find an ldlinux.sys (with these 
changes), it should be transferable to anywhere else.  Having a modified 
version means the two can be confused ("Well where did you get it from? 
  Did the installer make it?  Or is it renamed from the special one? ...")

- Shao Miller



More information about the Syslinux mailing list