Tabitha's Blog - Acer screwed up: How to (not) Secure Boot


Acer screwed up: How to (not) Secure Boot

This is picking up from the laptop review on last post. Upon installing Arch Linux, I forgot my install media plugged into the machine, which in this case was a Ventoy stick full of ISOs. After using sbctl to enroll the custom Secure Boot keys into the system's firmware:

tabby@calico ~> sudo sbctl status Installed: ✓ sbctl is installed Owner GUID: 9c2ef588-efb7-4f84-aede-cb0033482a6e Setup Mode: ✓ Disabled Secure Boot: ✗ Disabled Vendor Keys: none

I rebooted to double check the machine worked, as I'm well familiar with buggy UEFI implementations blowing up when someone actually bothers using Secure Boot with their own keys. Then, something peculiar happened: The machine booted into Ventoy. To explain why this is weird, here's a primer on Secure Boot.

Securing the x86 PC platform

PCs have suffered from the scourge of rootkits for a long time. Back in the XP days basically any machine could be owned from bootmgr upwards since most everything ran with Administrator permissions, no questions asked. With Vista and 7 things improved somewhat thanks to User Account Control, however people are conditioned to just hit "yes" on any dialog they're given and so, the problem continued. Microsoft decided to finally set things straight with Windows 8, by not only requiring UEFI boot for new machines, but also the new feature called Secure Boot.

Secure Boot leverages how the UEFI boot system is no longer confined by reading the first sector of your hard drive or whatever janky hell the Legacy PC platform uses to boot. It's now advanced enough where it just has a filesystem driver (if I recall the standard requires FAT support, but other filesystems can be supported by a vendor) and it uses that driver to open up a regular partition on a disk and look for a file, usually with a ".efi" extension, and chainload into that.

Secure Boot adds cryptographic verification to the boot process, through the use of public and private keys.

Every machine that ships with Windows 8 or newer requires Microsoft's digital signature to be installed to the Secure Boot database. Oversimplifying, Secure Boot has both an "allowed signatures" database and a "forbidden signatures" database, where leaked or otherwise insecure keys are added and the system checks and specifically blocks.

When the UEFI BIOS chainloads an EFI binary, be it an operating system chainloader or even an Option ROM, it will check its digital signature against the Secure Boot databases. If Secure Boot is enabled and is not in Setup Mode (more on Setup Mode soon), the system will check the signature of the file that's about to be loaded and if it's not in its database, or is in the forbidden signatures database, the system will refuse to load it.

However, Microsoft (to my knowledge) requires OEMs to allow you to not only disable Secure Boot, but also be able to enroll your own keys into the system, giving you full control over your computer's chain of trust, allowing it to only load binaries you trust and you signed yourself with your own keys.

The problem

Now, to get into Acer's screwup, we need to explain Microsoft's keychain. Microsoft has three Secure Boot keys that are enrolled on every PC shipping Windows:


I'm aware there's some rendering bugs on this page. I'm working on fixing them!
Fixed! Mercifully it only took about 15 minutes.
Luna Polendina
here it fuckin go

Add a comment

Your IP address will be saved alongside your comment, for anti-spam purposes.