Files, Volumes and Mounts at Boot

Abstract: How does booting "know" the Files, Volumes and Mounts even before the kernel begins, etc? This article is focused only on files, volumes and mounts.

1 Boot Devices, and Partitions

1.1 Master Boot Record on a HDD

Figure 1: Master Boot Record (MBR) disks, obsolete now. More than 4 partitions need a logical extended partition.

1.2 GUID Partition Table (GPT) Disks

GPT disks use Unified Extensible Firmware Interface (UEFI).
One advantage of GPT disks is that you can have more than four partitions on each disk.
GPT is also required for disks larger than 2 TB.

2 Before the Kernel Begins

Assume that the OS-boot-loader (OSBL), such as Grub, is in control. The kernel has not been invoked yet.
Does OSBL do any mounting? Yes. A file volume is mounted.
Volume must have been made already.
A path name in the mounted volume determines a file.
How does OSBL open, read and close files?
Where is the kernel? Ex: In the fisrt Grub stanza below (hd0,msdos1)/vmlinuz
OSBL gives the kernel an argument just as shell gives argv[] and argc to an invoked program that just became a process.

Study the Grub-2 stanzas below. [Minor inconsistencies are intentional.]

menuentry 'Linux Kubuntu Cosmic-Cuttlefish' {
 linux (hd0,msdos1)/vmlinuz ro root=/dev/sda1
 initrd (hd0,msdos1)/initrd.img
}

menuentry "Linux Knoppix 64-bit frugal-install" {
 linux (hd0,1)/boot/Knoppix/boot/isolinux/linux64 \
   knoppix_dir=/boot/Knoppix/KNOPPIX home=knoppix-data.img \
   lang=en_US keyboard=us desktop=kde
 initrd (hd0,1)/boot/Knoppix/boot/isolinux/minirt.gz
}

# note: findiso
menuentry kali-linux-amd64-iso {
  set isofile='/boot/iso/kali-linux-1.0.7-amd64.iso'
  loopback loop $isofile
  linux (loop)/live/vmlinuz boot=live findiso=$isofile\
    noconfig=sudo username=root hostname=kali \
    debug --verbose # nomodeset
  initrd (loop)/live/initrd.img
}

3 During the Kernel Startup

3.1 Background

Read up on the -o bind option.
Lookup pivot_root(8) and pivot_root(2)

3.2 Pivot

Assuming $_RUNFS is … and $SYSTEM is …, study this shell script. [Ellipsis is distro/ system dependent.]

mount -r $_RUNFS /mnt
for dnm in lib bin sbin usr
do
  mount -o bind /$dnm /mnt/$dnm
done
pivot_root /mnt /mnt/$SYSTEM
cd /
exec /sbin/init $*

4 After Init has Started

The root pivoted to is the root from now on.
All full-path-names are evaluated starting from this (new) root.
Does init process run in kernel or user mode? Who owns it?
What other processes begin chronologically before the init?

5 Security Implications

Where is the original pre-kernel root given?
Where is the during-kernel root to pivot (RTP) to given?
What if RTP is populated with Trojans, and other malware?
What if kernel invokes Trojaned init?
What if kernel itself is compromised? Who checks this?
Who checks the binaries, in /bin /sbin /usr/bin /usr/sbin, are good?
Who checks the libraries, in /lib /usr/lib, are good?

6 References

https://www.ibm.com/developerworks/library/l-linuxboot/index.html 2006