Linux kexec: Boot a Kernel Without Reboot

The kexec (kernel execution) system call in Linux provides a fast-path mechanism to load and boot into a secondary operating system kernel directly from the currently running system. By entirely bypassing the time-consuming hardware initialization, firmware routines (BIOS or UEFI), and external bootloaders like GRUB, kexec reduces system reboot times from minutes to seconds. This article examines the architectural role of kexec, how it manages memory and device states during a transition, and its critical utility in minimizing enterprise downtime and capturing kernel crash dumps.

The Mechanics of the kexec Workflow

Under traditional boot procedures, reloading an operating system requires a complete platform reset. The CPU executes firmware code, conducts a Power-On Self-Test (POST), detects and trains peripheral buses and memory, and hands execution over to a stage-one bootloader. On modern enterprise servers with dense hardware profiles and terabytes of RAM, this sequence can take tens of minutes.

The kexec subsystem eliminates this latency through a two-phase process:

1. Loading Phase (kexec_load / kexec_file_load): While the production operating system is fully operational, user-space utilities (such as the kexec-tools package) read the new kernel image, initial RAM disk (initramfs), and kernel command-line arguments into user space. The system call loads these segments into non-contiguous physical memory locations that the current kernel marks as reserved to prevent allocation corruption.
2. Execution Phase: When triggered (typically via kexec -e or during a crash event), the current kernel begins an orderly shutdown. It flushes filesystem caches, stops all non-boot processor cores (SMP tear-down), disables local interrupts, and suspends active device drivers.

Memory Relocation and State Transition

Because the target kernel usually expects to reside at a specific entry point in physical memory (often occupied by the active kernel), kexec utilizes an intermediate control code buffer—a small, position-independent assembly routine.

Once interrupts are masked and the MMU (Memory Management Unit) is configured for transition, the processor jumps to this control page. The control routine copies the new kernel segments from their temporary holding addresses into their final physical memory locations, overwriting the old kernel. The instruction pointer then jumps directly to the entry point of the new kernel, which boots using the provided parameters.

Modern Variants: kexec_load vs. kexec_file_load

The Linux kernel provides two primary system calls for handling kexec operations:

• sys_kexec_load: The legacy system call, which accepts pre-parsed segment arrays prepared entirely in user space. Because validation occurs largely outside the kernel, it presents security challenges regarding kernel image authenticity.
• sys_kexec_file_load: The modern system call, which accepts file descriptors for the target kernel and initramfs. This allows the kernel to verify digital signatures and enforce integrity policies, enabling kexec to function securely alongside UEFI Secure Boot and kernel lockdown modes.

Key Roles and Applications

• Enterprise Reboot Optimization: For high-availability servers, database nodes, and cloud hypervisors, kexec enables kernel patches and upgrades to be applied with negligible offline time, avoiding lengthy hardware re-initialization.
• Kernel Crash Dumps (kdump): The most critical application of kexec is kdump. When an active kernel suffers a fatal panic or oops, standard disk I/O routines cannot be trusted. Instead of executing an unsafe write, kexec instantly boots a minimal, pre-reserved "capture kernel." This capture kernel reads the physical memory of the crashed primary kernel (/proc/vmcore) and safely saves the crash dump to local storage or a remote server for post-mortem analysis.