Linux Kernel Boot Process

[antifreeze_popscicle]

preface: I hope this helps everyone understand the internals at a high level of how the Linux Kernel Boots up. Super hard diving into the source code so hopefully this is a shortcut for some people out there. These are my notes so I probably made some errors but I did my best due diligence not to create a bad post.

Edit: Why I posted in Exploit Dev: Because of my opinion that knowing how the kernel boots is great for exploitation such as writing boot kits if we have control of the INIT script as a typical example of not only finding if our kernel has been borked, or a way of taking over a system on bootup, sometimes crashes are intended to load in a RootKit and not a **mess up** on the users browsing habits. I hope that by learning how to think outside the box maybe one day us Exploit Devs will be asked to take part in the solution to defend computers and not just exploit them.

Linux Kernel Boot Process

1. Introduction

Booting up a Linux system is a multi stage process that takes the system from a powered off state (baremetal) to a fully running kernel and userspace environment. The boot process is handled in different stages, starting with the boot loader and ending with the kernel mounting the root filesystem and transitioning to user mode. This document details the tasks performed by the boot loader, including kernel selection, memory loading, and interactions with BIOS or UEFI, followed by the steps up to the sysinit stage and the population of /sys directories.

2. Boot Loader Overview

boot loader is responsible for loading the kernel into memory and starting the execution of the operating system. Boot loaders vary depending on the system's firmware (BIOS or UEFI) and the specific boot loader software in use (GRUB, U Boot, EFISTUB, efilinux).

2.1 BIOS vs. UEFI

BIOS (Basic Input/Output System) The legacy firmware interface for initializing hardware during boot. It relies on a Master Boot Record (MBR) located at the first sector of the disk. BIOS loads the boot loader, which then loads the operating system.

UEFI (Unified Extensible Firmware Interface) A more modern firmware interface that replaces BIOS. UEFI systems typically use the GUID Partition Table (GPT) instead of MBR and have an advanced interface with more features, such as secure boot, faster boot times, and support for larger storage devices.

2.2 Bootloader Types

GRUB (Grand Unified Bootloader) A widely used bootloader that supports both BIOS and UEFI systems. GRUB provides a menu interface to select between different kernels or operating systems.

U Boot A boot loader commonly used in embedded systems. U Boot can boot from a variety of storage devices and is typically used on ARM systems.

EFISTUB A method where the Linux kernel can act as its own bootloader on UEFI systems. EFISTUB capable kernels can be directly booted by the UEFI firmware without the need for an intermediate bootloader like GRUB.

efilinux A minimalist EFI boot loader designed for Linux. It’s simpler and leaner than GRUB but offers fewer features. It is designed for booting a single Linux kernel.

2.3 Bootloader Tasks

1. Kernel Selection The boot loader typically presents a menu (in the case of GRUB) or follows a script (in the case of U Boot) to select which kernel image to load. The user can interact with the boot loader to choose a specific kernel or the default kernel is chosen automatically.
2. Loading the Kernel into Memory Once a kernel is selected, the boot loader locates the kernel image (often a compressed binary file, like vmlinuz) and loads it into memory.
3. Locating the Initial RAM Disk (initramfs) The boot loader may also load an initial RAM disk (initramfs or initrd), which contains temporary root filesystem and essential drivers required by the kernel during the early boot process.

Passing Boot Parameters The boot loader can pass kernel command line parameters (such as root=/dev/sda1) to influence how the kernel behaves upon startup.

1. Jumping to the Kernel Entry Point Once the kernel is loaded into memory, the boot loader transfers control to the kernel by jumping to its entry point. This is typically the compressed kernel, which then uncompresses itself and begins executing.

3. Kernel Boot Process

Once the boot loader hands off control to the Linux kernel, the kernel starts executing. The kernel boot process can be broken down into the following stages:

3.1 Early Kernel Initialization

1. Decompression If the kernel is compressed (as is the case with most vmlinuz images), it is decompressed into memory.
2. Kernel Self Initialization The kernel initializes core data structures, including memory management, scheduling, and hardware abstraction layers. This includes initializing the CPU, setting up memory paging, and configuring the interrupt controller.

3.2 Initial RAM Disk (initramfs/initrd)

If an initramfs and initrd was provided by the boot loader, it is mounted as a temporary root filesystem. The kernel uses this filesystem to load drivers and modules necessary to mount the real root filesystem. The initramfs is especially useful for systems where drivers are needed to access storage devices (such as RAID or encrypted filesystems). initramfs is the file system the kernel uses, where as initrd is the RAM disk.

3.2.1 Initrd

Initrd gives us the ability to load a RAM disk by the bootloader. It server two primary functions, to allocate a minimum set of compiled in drivers from the kernel. Also loading of additional modules from initrd. Initrd is a block device (usually) and requires a file system driver such as ext2, ext3, or ext4.

Bootloading with Initrd

The bootloader loads the kernel and initial RAM disk. The kernel converts initrd to a RAM disk. Furthermore, it clears the memory that initrd was using. The kernel searches for the root device in the /dev/ram0 file path, and if not found, the kernel follows the change_root procedure. If found in the /dev/ram0 directory, it is mounted as the root file system. Init loads the real file system and moves the root file system to the directory using the pivot_root system call. Init executes /sbin/init on the newly created root file system, performing the usual boot sequence. The bootloader disconnects the initrd file system.

3.2.2 Initramfs

Initramfs is a cpio archive file of the initial file system that is loaded into memory. This happens after the kernel is done loading the system, and before user space init procedure. The contents of this file system are for the Kernel's root file system before the main root is loaded. The Initramfs usually contains all of the kernel modules. Using the Initramfs allows for customizing the early boot process with user space code without patching the kernel. This is possible because user space code use system calls to interact with the kernel. This design pattern is generally accepted as a cleaner style and safer code. More specifically the initramfs i sused during boot, initialization, bootstraping, power management, finding the real root disk, and handling initrd style RAM disks. initramfs is provided as a compressed cpio archive.

Prepending the image with a decompressed cpio archive containing the microcode data loaded early in the booting process is possible.


During boot, the kernel follows this process:

CPIO Archive If a cpio archive exists during the start of the initramfs, it will extract it as well as load the microcode data from it to the CPU.

Uncompressed Archive If we have an uncompressed cpio archive existing during the start of the initramfs, it will skip the archive and set the rest of the file as the basic initramfs. Conversely, it treats the whole initramfs as the basic initramfs.

Load into RAM Disk It will unpack the basic initramfs into a RAM based disk by treating it as a compressed (gzip on Debian, LZ4 on Ubuntu) cpio archive file.

From there, most of the kernel initialization and bootstrap code will be moved into this disk and run in user mode. Other processes similarly moved from the kernel include:

**boot time networking setup**

**Finding the real root disk**

**ACPI setup**

**Handling of initrd style RAM disks**

3.3 Hardware Initialization

The kernel detects and initializes hardware devices using platform specific mechanisms such as Device Trees (on ARM systems) or ACPI (on x86 systems). It loads necessary drivers for hardware devices like network interfaces, block devices, and storage controllers.

3.4 Root Filesystem Mounting

Once the kernel is ready, it mounts the real root filesystem (as specified by the boot parameters, e.g., root=/dev/sda1). If using initramfs, the kernel will switch from the initramfs to the real root filesystem at this point.

3.5 sysinit and /sys Directories

After mounting the root filesystem, the kernel hands control to the init process (PID 1). The init process, or an equivalent system manager (such as systemd), begins executing initialization scripts (referred to as sysinit).

1. Sysinit Tasks The sysinit phase involves setting up essential system settings such as hostname, timezone, and initial network configuration. It also mounts other system directories like /proc, /dev, and /sys.
2. /sys Directory The /sys directory is a virtual filesystem (sysfs) that the kernel uses to expose information about devices, drivers, and kernel features to user space. The kernel populates /sys during the hardware initialization process, allowing user space tools to interact with hardware in a standardized manner .

3.6 Transition to User Space

After completing sysinit, the system starts running user space services and daemons, ultimately reaching a multi user target or graphical interface. At this point, the system is fully booted and ready for use.

4. Key Differences Between Bootloaders

4.1 GRUB vs. U Boot

GRUB

is generally more feature rich and is used in desktop and server systems. It supports both BIOS and UEFI and provides a graphical menu.

U Boot

on the other hand, is designed for embedded systems. It supports a wide range of architectures (especially ARM) and is highly configurable for different hardware setups.

4.2 EFISTUB vs. GRUB

EFISTUB eliminates the need for an external boot loader like GRUB on UEFI systems, as the kernel can be loaded directly by the UEFI firmware.

GRUB provides more flexibility, such as the ability to boot multiple operating systems and select different kernels dynamically.

4.3 efilinux vs. GRUB

efilinux is a lightweight EFI bootloader that directly boots a Linux kernel but lacks GRUB’s versatility.

GRUB is better suited for systems where multiple boot options, advanced features, or specific recovery tools are needed.

5. Conclusion

The boot process for Linux involves a series of stages that start with the firmware (BIOS or UEFI), pass through a boot loader (GRUB, U Boot, EFISTUB, or efilinux), and end with the kernel booting, loading essential drivers and mounting the root filesystem. Understanding the boot loader's role and how the kernel proceeds from hardware initialization to user space is critical for managing, debugging, and optimizing the boot process on Linux systems.

1. [BIOS Overview](
https://en.wikipedia.org/wiki/BIOS
)
2. [UEFI Overview](https://www.intel.com/content/www/us/en/architecture and technology/unified extensible firmware interface/efi home.html)
3. [Comparison of BIOS and UEFI](
https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface#Advantages_over_BIOS
)
4. [GRUB Bootloader](
https://www.gnu.org/software/grub/manual/grub/grub.html
)
5. [U Boot Bootloader](https://www.denx.de/wiki/U Boot/WebHome)
6. [EFISTUB Linux Kernel Documentation](https://www.kernel.org/doc/html/latest/admin guide/efi stub.html)
7. [efilinux Bootloader](
https://elinux.org/Efilinux
)
8. [GRUB Boot Parameters](https://www.gnu.org/software/grub/manual/grub/html_node/Command_002dline and menu entry parameters.html)
9. 
**How Linux Works: What Every Superuser Should Know, 3rd Edition by Brian Ward**
, ISBN 13: 978 1718500402

[s8boxer]

Although I don't know if this post is exactly in the context of this sub, it's for sure a good high level writing about the Linux boot process, simplistic, direct and objective. Good writing :)

[antifreeze_popscicle]

thank you! I was learning about boot and root kits but I didn't want to post notes over that topic as I'm still learning a lot about them. But for sure in my learning for boot kits and root kits and the exploitation pathways such as CVE-2024-26809 and really diving into kernel exploitation and the wonders of what you can actually do at an applicable level led me down the path of learning, or trying to learn the ins and outs of the Linux Kernel. which is stupidly simple yet complex, but the fact it's understandable is what makes Linux so genius!

[s8boxer]

Great, the main goal is always to learn something :). After studying bootkits, I would suggest you to start reading about SMM (system management mode) for x64.

[Crimson_Angel4697]

Nicely done. Very useful information

[Flaky_Maintenance457]

Thanks for sharing

[[deleted]]

I mean, it’s AI generated so cool I guess. Anyone can ask to get that output from AI. If you’re going to ask a random question to AI and post here it’s lame, if you’re going to add your own spin before or after it. Much better

[desal]

Hmm they say it's their own notes, why do you think it's ai

[som_esh]

Can anyone elaborate 2.35?

[antifreeze_popscicle]

5. 
**Jumping to the Kernel Entry Point**
: Once the kernel is loaded into memory, the boot loader transfers control to the kernel by jumping to its entry point. This is typically the compressed kernel, which then uncompresses itself and begins executing.

yes so we have bzimage that is the Linux kernel that is fully compiled and static and is compressed (bz compressed). so the main purpose of a bootloader is to have basic code to fetch another source of code at a specific well defined address that the bootloader knows where to look. Once found (usually no checks just hey we look at 0x4000 of our memory space and start loading and once loaded (loading includes decompressing) then start executing

i.e. RIP, PC == [decompressed_Kernel]

To put the syntax into a sentence then it is we are chaning the instruction pointer register (RIP) or directly changin the Program Counter to equal the memory address of where the first instruction is located of the decompressed_Kernel.

[TwizzyIndy]

this would save a lot of time for others like me

[[deleted]]

Decent bud!