Who Controls What Happens Before Linux Starts?
Before Linux Starts: Exploring a More Open Boot Process
Exploring ways to make the start-up process easier to inspect and give owners greater control over how their machines boot.
Most of this happens out of sight, but it plays an important part in the security and reliability of the laptop.
Star Labs is exploring several ways to make this part of the start-up process easier to inspect and give owners greater control over how their machines boot. Heads could help owners check that important parts of the start-up process have not changed unexpectedly. Universal Payload and cdk2 explore different ways for the firmware to hand over to the next stage, while active verified boot is designed to prevent unapproved software from running. In the longer term, Linux itself could take on more of this role.
Checking the boot process
Helps explore ways for owners to check important parts of the start-up process before Linux loads.
A consistent handover
Explores different ways for the firmware to hand control to the next stage.
Verify before running
Designed to prevent unapproved software from continuing through the start-up process.
These are separate projects rather than a single new feature. What connects them is the aim of offering owners more choice without losing the things that make a laptop dependable, including signed updates, saved firmware settings and a reliable recovery process.
Heads support has been submitted for review, while cdk2 and active verified boot still require further testing. Using Linux as part of the boot process remains a longer-term project. None of these options replaces the standard boot software supplied on Star Labs laptops today.
Heads: Checking the Boot Process Before Linux Starts
Heads is a LinuxBoot environment designed to help owners check important parts of the start-up process before the operating system loads. It uses measured boot and the laptop’s Trusted Platform Module, or TPM, to record information about what has run. It can then check expected files and provide a controlled place to continue into the operating system or recover from a problem.
Our current work supports essential features such as storage, USB devices, the built-in keyboard and recovery. Automated build and firmware-storage checks have passed for 14 hardware configurations included in the project. An earlier test on Triangle-class Cezanne hardware also successfully started Ubuntu through Heads. However, the work is still being reviewed and further testing on physical hardware is required.
Hardware limitations: Three older configurations, LabTop KBL, StarLite GLK and StarLite GLKR, do not have enough firmware storage to hold the current Heads image safely.
We have therefore marked them as unsupported rather than trying to fit the software into space that is too limited.
The potential benefit for users is greater visibility and control. Heads could help identify unexpected changes before the laptop completes the start-up process, while also providing a clear route to recovery if something goes wrong.
Universal Payload: Creating a More Consistent Handover
Coreboot prepares the laptop’s hardware before the operating system starts. It then passes control to another piece of software, known as a payload, which continues the boot process. Universal Payload aims to make this handover more consistent across different models, reducing the need to develop a separate approach for each one.
This work also supports the development of cdk2, a Rust-based UEFI environment. Rust is designed to prevent some common memory-related errors, although using a memory-safe programming language cannot remove every possible firmware risk.
An earlier test on a Meteor Lake StarBook showed cdk2 working with saved firmware settings, sleep, hibernation and memory encryption.
We are now developing a more direct connection between coreboot and cdk2. This route still requires hardware testing, particularly around putting the laptop to sleep and waking it again. The earlier result shows that the individual components can work together, but the more direct approach is not yet finished or ready for customers.
Why this matters: A more consistent handover could eventually make it easier to support different boot options across the Star Labs range while retaining saved settings, power-management features and security protections.
Active Verified Boot: Stopping Unapproved Software Before It Runs
Active verified boot checks that the laptop’s firmware is approved before allowing the start-up process to continue. It is also designed to prevent an unsuitable older version from replacing a newer one.
Software testing has shown that approved firmware is accepted, while damaged, unapproved or unsuitable versions are rejected. We have also tested what happens if the process is interrupted at 72 different points. However, the first physical test on a StarLite GLK did not complete successfully. The candidate firmware was rejected because its signing identity did not match the identity fused into the machine’s Intel Boot Guard configuration.
The laptop was recovered safely, and the mismatch was not bypassed.
What the result tells us: This is useful evidence that the machine responded safely, but it does not mean that active verified boot has completed its hardware testing or is ready for customers.
For owners, the principle is straightforward. If the firmware cannot be verified, the laptop should stop safely rather than continue with software it does not trust.
Different Boot Options, One Signed Update Process
Offering different boot options would become impractical if each one needed its own way of storing settings and installing updates. We are therefore designing Universal Payload, Heads and the planned Linux option to use the same update process and firmware-storage structure.
Signed updates
Updates would continue to be delivered through the Linux Vendor Firmware Service.
Firmware checks
Before installing an update, the laptop would check that it is intended for the correct model, uses an acceptable version and has a valid signature.
Protected firmware
The boot environment can request an update, but it cannot make unrestricted changes to the firmware.
Recovery
We are also testing how the update process responds to interruptions, restarts and other problems. Any update method that has not yet been shown to work safely remains restricted or disabled.
The principle: Choosing a different boot environment should not mean accepting a less reliable update process.
The aim is for every supported option to retain signed updates, saved settings and a dependable way to recover if something goes wrong.
Giving Owners More Choice
Different people want different things from their laptops. Some may prefer the familiar start-up process available today, while others may want more ways to check what happens before Linux starts. In the future, we hope to offer owners more choice over this part of their machines.
Whatever options become available, they should all retain the features that make a laptop dependable. Updates should remain secure, settings should stay saved and there should always be a reliable way to recover if something goes wrong.
What comes next: These projects are still being developed and tested, so the details may change. The goal, however, is simple: to make the start-up process easier to understand, harder to change without the owner knowing and more firmly under their control.