KOS Boot Process
Introduction
To support verified boot with immutable components, the boot process for KOS differs significantly from standard desktop distributions. KOS must select and verify a set of immutable system components and then combine them all into the final root filesystem. Once the overlay root is assembled, KOS hands off control to the standard systemd init process to continue the boot in a normal fashion. The major stages of the KOS boot are outlined below.
Step 1: Bootloader/BIOS Handoff
KOS takes control of the system when the BIOS or first-stage bootloader invokes KOS’s Boot Kernel – a basic Linux kernel/Initramfs with sufficient support to read and validate the contents of the ImageFS. When secure boot is available from the BIOS, the Boot Kernel may be signed to establish a chain-of-trust.
Step 2: Boot Kernel Selects the Boot Solution
The Boot Kernel is responsible for finding and mounting the ImageFS. Once this is done, it walks through the list of active manifests and selects the first one that is valid. Criteria for validating a manifest include:
-
The manifest is signed with a trusted key
-
All components named by the manifest exist and match their specified sha256 hashes
Once the Boot Solution is selected, the Boot Kernel attempts to launch it.
Step 3: Boot Kernel Launches the Boot Solution
Boot Solutions normally specify not only filesystem images, but also a Linux kernel and initrd. To launch the Boot Solution, the Boot Kernel uses the Kexec system call to relaunch into the new kernel specified by the manifest (the System Kernel). When launching the System Kernel, the Boot Kernel specifies a kernel command line that tells the new kernel what manifest is being booted so that it can continue the boot process accordingly.
Step 4: System Kernel Mounts Image Components
Once the System Kernel’s Initrd is in control, it rediscovers the manifest that was specified by the Boot Kernel. The System Kernel walks through the manifest’s list of image components, and mounts each image to a unique directory under /mnt. Each component may require multiple steps to mount. For example, filesystem images may be encrypted, requiring a key lookup and a loopback mount.
Step 5: System Kernel Mounts a R/W Runtime Cache
In addition to the one or more read-only images, the System Kernel creates a single read-write mountpoint to be used in the OverlayFS. By default, the R/W filesystem is cleared on each boot so that unintentional or malicious run-time side-effects are never propagated across boots. A separate DataFS is available for storing persistent data.
Step 6: System Kernel Combines Image Components And R/W Cache into an OverlayFS-based RootFS
Once all component filesystems are in place, the System Kernel mounts a combined OverlayFS consisting of the many separate pieces. This new aggregate filesystem will become the final system RootFS. The images are stacked in the overlay in the order in which they appear in the manifest, so the first listed component is on the bottom of the stack with the lowest priority.
Step 7: System Kernel Switches to the new RootFS
When the final root filesystem stack has been assembled, the System Kernel’s Initramfs performs a ‘Switch Root’ operation to pivot into the new RootFS. systemd init is started, and startup proceeds much like any other distribution. KOS is now running a complete Linux system verified by a chain of trust rooted in either the hardware or Boot Kernel.
