Who Controls What Happens Before Linux Starts?
Engineering preview
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 working on 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 can help owners check that important parts of the start-up process have not changed unexpectedly. Universal Payload explores a more consistent way for the firmware to hand over to the next stage, while VBOOT 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 owners check important parts of the start-up process before Linux loads.
A consistent handover
Explores a more consistent way 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 upstream and is awaiting merge. VBOOT is complete and awaiting rollout, while 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 Linux 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 hardware test also successfully started Ubuntu through Heads.
The upstream pull request has not yet been merged, so this work is still in progress.
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 can 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.
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.
VBoot: Stopping Unapproved Software Before It Runs
VBOOT 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.
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.
Development of VBOOT is now complete. It has not yet been rolled out to customers, but we expect deployment to begin soon.
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: Some of this work, including VBOOT, is approaching customers, while other projects remain in development or upstream review. The broader goal is the same: to make the start-up process easier to understand, harder to change without the owner knowing and more firmly under their control.