One of Purism’s core beliefs is to ensure that to the best of our ability, all new features, fixes, and improvements will be applied to all products, past and present. With that in mind, we’re excited to share with you the many improvements to our coreboot-based firmware over the past few months:
We’ve also been busy improving our tamper-evident PureBoot firmware:
coreboot 4.11 was mostly a clean-up release, but since we skipped over 4.10 (due to some regressions affecting Skylake/Kabylake platforms) this release effectively includes over a year’s progress on the coreboot codebase. Rather than enumerate all the changes, we’ll just link to the release notes:
One of the biggest additions to coreboot as part of the 4.11 release was the addition of coreboot native graphics init (libgfxinit – a Spark-based ancillary project to coreboot) support for the Broadwell, Skylake, and Kabylake platforms. This allowed us to give the VBIOS the old heave-ho, and replace it with clean, auditable, safe code. Ditching this legacy blob also helped us with the next improvement…
One of the biggest issues with the use of the VBIOS to initialize the display was we had no control over what it did. It would init the display in VGA text mode (640×400), switch to a VESA-compatible mode (1280×1024) to show the boot splash, switch back to VGA text mode before booting, and finally switch to the panel native resolution when the OS driver loads. Now, we use a single resolution up until the OS driver loads, and have ensured that the boot splash is the first thing displayed.
Shortly after the first speculative execution vulnerabilities were discovered back in early 2018, Intel released microcode updates to help mitigate them, and has continued to do so in the time since. While microcode updates can also be loaded by the OS, the user is best protected when they are done by the system firmware, and applied in conjunction with mitigations at the OS level. To that end, Purism aims to release firmware updates quickly whenever new CPU microcodes are released. Our current 4.11-Purism-1 release (and PureBoot beta-11 release) include the latest microcode for each platform.
A problem that had plagued all PureBoot betas to date, this issue was caused by HEADS not correctly passing some command-line arguments to the Xen hypervisor. Qubes 4.1 should now be fully functional on Librem devices running PureBoot, same as those running our standard coreboot/SeaBIOS firmware.
With the release of Fedora 30, a new dynamic format grub.cfg was introduced, which stores boot menu entries in individual files using bootloader spec (BLS) format. Patches were added to the upstream HEADS project to parse these files and allow booting of distros using them.
Another long-standing issue had been the corruption of the display (often seen as a brief rainbow flicker) when booting an OS from PureBoot. This was caused by a misconfiguration of IOMMU for the HEADS Linux payload and has now been fixed.
Until now, HEADS/PureBoot assumed a static default boot device, and if the user’s config differed, required non-trivial intervention to select and save the boot device, update the firmware, reboot, and then re-sign all files in the /boot partition. Now PureBoot will automatically detect the correct /boot device at startup (the user can still change/override if needed). Although a relatively small change, it has a big improvement in user experience, and is one of the many such improvements Purism has contributed to the HEADS project.
On the flip side, the Factory/OEM Reset Function is one of the larger changes Purism has contributed. While the impetus for the change was to streamline setup at the factory, this can be used anytime a clean start is desired and essentially makes the configuration of PureBoot (and HEADS) a 1-click operation. It will reset the TPM, reset your Librem key, generate new GPG keys (and back up to USB), load them into the firmware, configure the boot device, and sign all files in /boot.
We’re continually working to make the PureBoot user experience simpler, easier, and more friendly. One of the ways we do that is to provide error messages, dialogs, etc which give the user a clear understanding of what happened, why it happened, and what action they need to take. The past few PureBoot betas have made significant strides on that front.
While there aren’t any specific feature of which to speak, we certainly have no intention of slowing down. For instance, PureBoot is currently undergoing an internal UX review and once we have smoothed out some more rough edges in the UI we hope to be announcing the 1.0 release of PureBoot. A big thanks to all our current beta testers who have provided their feedback and ideas.