The creator of systemd (Lennart Poettering) has recently created a new company dedicated to bringing hardware attestation to open source software.
What might this entail? A previous blog post could provide some clues:
So, let’s see how I would build a desktop OS. The trust chain matters, from the boot loader all the way to the apps. This means all code that is run must be cryptographically validated before it is run. This is in fact where big distributions currently fail pretty badly. This is a fault of current Linux distributions though, not of SecureBoot in general.
If this technology is successful, the end result could be that we would see our Linux laptops one day being as locked down as an Iphone or Android device.
There are lots of others who are equally concerned about this possibility: https://news.ycombinator.com/item?id=46784572
Secureboot uses certificates to verify integrity. The user is able to install new certificates. So I’d say it is the user? I’m not an expert though and their may be hardware out there that doesn’t allow new certificates.
That’s true today, but there’s no guarantee it will be true in the future. Google is already pushing for all software running on Android to be cryptographically verified and they (Google) are the only ones that control the signing keys. This means that they intend to kill off F-droid and all other software delivered outside the Google store.
If Google is able to pull it off on Android, everyone else will try to do it on desktop OSes too - Linux included.
It’s in the specification.
It’s a matter of clearing the platform key & enrolling your own platform key. I’ve done this before.
Typically, computers with Secure Boot let us clear the platform key from the boot menu. (You can choose to purchase only those that do.) Some computer vendors ship Secure Boot in setup mode or let the customer provide public keys to ship preloaded.
Secure Boot has always been for enabling the owner to enforce integrity of the boot process through cryptographic signatures. Linus Torvalds thought the feature makes sense.
That’s right. The user (or administrator if it’s a work machine) installs or removes acceptable certificates into firmware database. Typically a device you buy in the past 15 years or so comes with Microsoft certificates preinstalled, but it doesn’t have to stay like that.
AFAIK, the allowing the user to install and remove certificates is a x86_64 thing only, arm will happilly fuck you over, x86_64 UEFI implementations ARE REQUIRED TO add that feature to be spec compliant, this was a intentional decision by Intel and AMD to keep x86_64 open to new OS and not locked down to Windows which could one day be a sinking ship, so that x86_64 would not be at the mercy of Microsoft’s success and attachment to the platform
I have seen some platforms locked to Microsoft first party keys only. They boiled the frog by starting with it being optional, able to enroll your own keys, and Microsoft signing third party bootloaders, but now there exists a Microsoft-only certificate regime that at least some vendors have selected, or at least made a selectable option. The pitch being that Windows shops that don’t trust their users can be assured they aren’t deviating from the blessed windows os their IT trusts.
Can’t say it’s obvious how to change certificates on my motherboard. Just updated the BIOS and had to turn off SecureBoot so it could boot into my Linux install (MSI B450 Tomahawk Max).
Every bios I’ve used has 2 sets of certificates built in. The default one is the Microsoft production certificate and the Linux bootloader doesn’t match. But their should be another certificate for open source systems that will work.