Hi Syslinuxers, I am trying to understand the basic load chain in fat32 and ext4. I dug into the assembly for MBR, which is pretty straightforward: 1. Find boot partition (or use the pre-defined one at byte 440 for altmbr.bin) 2. Load the first 512-byte sector of the partition (VBR for fat32, Block Group 0 padding for ext). 3. Execute that code The code that is loaded, however, has to be too small (even if using entire 1024 bytes of padding in ext4) to understand ext4 and/or fat32, let alone find and read the syslinux.cfg file, present menu, and eventually execute a linux kernel. I assume that is the job of ldlinux.sys and the various .c32 modules. 1. Where is the code that goes in the VBR or Block Group 0 padding? 2. What does it execute? Does it just find the ldlinux.sys and execute it? 3. How does it know to find the ldlinux.sys (and, at the least, ldlinux.c32) if it cannot read the filesystem? Does syslinux --install copy them over and then read the filesystem to know precisely what blocks they are in and then embed the precise block number in the VBR? Where? And if so, does it not leave it vulnerable to the files being moved around? Thanks in advance. -- Avi Deitcher avi at deitcher.net Follow me http://twitter.com/avideitcher Read me http://blog.atomicinc.com
On Mon, Jan 1, 2018 at 11:06 AM, Avi Deitcher via Syslinux <syslinux at zytor.com> wrote:> Hi Syslinuxers, > > I am trying to understand the basic load chain in fat32 and ext4. I dug > into the assembly for MBR, which is pretty straightforward: > > 1. Find boot partition (or use the pre-defined one at byte 440 for > altmbr.bin) > 2. Load the first 512-byte sector of the partition (VBR for fat32, Block > Group 0 padding for ext). > 3. Execute that codeYep.> The code that is loaded, however, has to be too small (even if using entire > 1024 bytes of padding in ext4) to understand ext4 and/or fat32, let alone > find and read the syslinux.cfg file, present menu, and eventually execute a > linux kernel. I assume that is the job of ldlinux.sys and the various .c32 > modules.ldlinux.sys is ldlinux.bin without the VBR (Volume Boot Record) code.> 1. Where is the code that goes in the VBR or Block Group 0 padding?diskboot.inc.> 2. What does it execute? Does it just find the ldlinux.sys and execute it?Set up the basic environment, load blocks of ldlinux.sys, check integrity (weakly but works well enough) and jump to a further point. The installer patches in a block map of ldlinux.sys into the VBR plus ldlinux.sys. At least one record stating N sectors at volume offset M needs to live in the VBR. Often, only 1 record is needed.> 3. How does it know to find the ldlinux.sys (and, at the least, > ldlinux.c32) if it cannot read the filesystem? Does syslinux --install copy > them over and then read the filesystem to know precisely what blocks they > are in and then embed the precise block number in the VBR? Where? And if > so, does it not leave it vulnerable to the files being moved around?Files moving from directories shouldn't be an issue (unless it's a copy/delete). It certainly is vulnerable to moving the underlying blocks hence why ldlinux.sys resides in the special reserved space in btrfs. -- -Gene
Thanks for the response, Gene. Much appreciated. I didn't get all of it; mind if I follow on below? ldlinux.sys is ldlinux.bin without the VBR (Volume Boot Record) code.>Makes sense.> > 1. Where is the code that goes in the VBR or Block Group 0 padding? > > diskboot.inc. >which appears to be included in diskstart.inc. I will have to dig in and see how this all gets compiled (pointers always appreciated :-) ). An install on Linux (before I run "syslinux --install") actually doesn't have ldlinux.sys or ldlinux.bin anywhere. Are they embedded into the syslinux binary and it installs bytes, vs copying from the local filesystem?> > 2. What does it execute? Does it just find the ldlinux.sys and execute > it? > > Set up the basic environment, load blocks of ldlinux.sys, check > integrity (weakly but works well enough) and jump to a further point. > > The installer patches in a block map of ldlinux.sys into the VBR plus > ldlinux.sys.A blockmap into the VBR and ldlinux.sys into the VBR?> At least one record stating N sectors at volume offset M > needs to live in the VBR. Often, only 1 record is needed. >I didn't get this part. Record?> > > 3. How does it know to find the ldlinux.sys (and, at the least, > > ldlinux.c32) if it cannot read the filesystem? Does syslinux --install > copy > > them over and then read the filesystem to know precisely what blocks they > > are in and then embed the precise block number in the VBR? Where? And if > > so, does it not leave it vulnerable to the files being moved around? > > Files moving from directories shouldn't be an issue (unless it's a > copy/delete). It certainly is vulnerable to moving the underlying > blocks hence why ldlinux.sys resides in the special reserved space in > btrfs. >But wouldn't work in FAT32 (VBR = 512 bytes) or ext4 (1024 bytes in Block Group 0). Thanks again for the explanation. Avi