New Post: Introducing PureBoot Restricted Boot

We have been busy on the PureBoot front! Recently we announced “PureBoot Basic Mode” which is a low-security option for PureBoot that disables tamper detection, but leaves you with the robust PureBoot recovery console for debugging boot issues. To balance our last “low security” feature, our most recent PureBoot release, version 23, offers a new high-security feature called Restricted Boot . By default PureBoot will allow you to boot any USB disk you choose, and offers a failsafe boot mode so you can boot into your system even if signatures don’t match. Restricted Boot tightens down boot security so you can only boot trusted, signed boot images. In this post I will describe the thinking and design behind Restricted Boot and how it contrasts with boot restrictions on other platforms.

Read the rest of the topic here:


A good improvement. May even silence some of the social media haters. :wink:

One thing that I wonder about is … what happens if /etc/distro/keys has no keys?

Since there wouldn’t be much call for Restricted Boot with no keys, should it in that case offer to import a key from somewhere (presumably USB)? The expectation would be that only the legitimate owner will ever and can ever remove all keys using the UI and the owner would do that only temporarily while getting rid of the default keys and installing the one trusted signer’s key. The benefit is a relatively simple UI to achieve what might be the most common situation (and without forcing the customer to build Pureboot from source). The downside is that you would have to lock that functionality down somehow.

Perfect for the retiree who has trouble learning new things, like keeping track of keys.

(Unless you’re like Gene Hackman in: “Enemy of the State”.)

If that directory is empty, then you wouldn’t be able to boot from any USB image (which some users might consider a feature). You would still be able to boot from your locally-installed OS however, as long as you maintained proper signatures for the files in /boot.

As I mentioned in the post, we do want to add the ability to import new keys to the keyring using a GUI (we already have this functionality in the GPG menu for OS signing keys, so we can likely reuse a lot of code). We just haven’t implemented it yet.


There are definitely environments where that is the desired outcome.

For me though, let’s say that sooner or later I may mess something up so that the operating system on the internal disk becomes broken and I want to boot from USB in order to fix things up. :rofl:

Or I just want to do a backup …

Yes, it’s exactly this sort of thing that factored heavily into our design. I didn’t want people to be locked out of their computer because they forgot a PIN or made a mistake. That’s why you can always disable Restricted Boot and get back all of your recovery tools, boot any USB disk you want, etc.

1 Like

When I enabled restricted boot on my Librem Mini V2 system it spewed a bunch of error messages at the “save the current configuration to the running BIOS” step, then eventually performed the reflash of the BIOS. I tested with a USB boot stick and it’s working. Don’t see any /etc/distro/keys dir on my system, is that something created manually by the end user that wants to boot from trusted USB sources?

Interesting. I imagine the errors might have to do with the lack of TPM in the Mini.

The /etc/distro/keys directory is within the PureBoot runtime, not within your OS. To check it out you would need to exit out to the recovery console (which you can’t do in Restricted Boot) and to change it you would need to re-build a PureBoot image from source.

Here’s some screenshots. Sorry I misdescribed the Warnings about Setting BIOS controls as errors.

Verified that restricted boot setting is working by attempting an unsigned USB stick boot:

Ahh, those warnings may be more due to a new coreboot version but I’m not really an expert on that part of it.

I just installed latest version of PureBoot (v23) released 4 days ago as of this writing

What I mean is that we updated coreboot as well on either that or the previous version of PureBoot, and it’s possible if you haven’t updated in awhile, that a new version of coreboot could be the cause of warnings you saw when updating to this release.

I remember this behavior, i.e. the multiple Calibrating delay loop messages, on a previous version of Coreboot/Pureboot. To someone not familiar with the software it ‘feels’ like it’s attempting to do the same thing again and again, unsuccessfully. I can’t remember with 100% certainty, but I recall my first attempt at enabling restricted boot, and then saving the config to the running BIOS, did the same thing, except after the four calibrating delay loop messages, it just gave up and kicked me back to the menu without reflashing the BIOS. Second time is a charm in this case apparently.

My previously installed Pureboot was v21 if that’s of note.