Getting Secure Boot to work

I invite you to learn my native language, so I can pick on your grammar.

Point being, prebootloader was used in combination with gummiboot(systemd-boot) on our install media, not any longer, we use grub now.

Good then. It doesn’t make all that big deal though, as I was saying.

So… I’m quite still waiting™, and I spent some time following accounts over UEFI signing.
It doesn’t seem really easy (or cheap!) nowadays.

Looking better in other news, shim hasn’t any [boot]loader constraint, but it kinds of have the problem that it will only help as far as images are signed (with the same “distro key”) in their turn.
It should even support enrolling hashes, but ofc user should just find out everything lied down for them.
I found out Fedora has a quite nice (and free??) signing service for other distributions.
Given the “target audience” of upstream (aka I usually compile kernel on my own) I guess it wouldn’t really help there… Though manjaro has a different one and I don’t think not-even-having-to-enroll-hash-like-with-preloader wouldn’t be that bad.

EDIT: soo… I’d kind of keep this thread about “manjaro officially shipping the thing for itself” or something.
“I want to sign my own stuff” instead… Going here I guess?

EDIT2: just now realized, we can suppose shim should be able to work for 3 use cases:

  • enrolling hashes
  • enroll just any signing key - manual physical access required each time
  • enroll one specific signing key - automatic (requires submission to shim review board)

Porting over my FAQ, from the “dangers” thread, since I discovered off-topic section is off-limits to the outside world. Also, for others, I slightly edited post above.


Q1: Secure Boot is an evil scheme by microsoft to lock user on Windows
A: SB is a feature that should be present in every system with UEFI >2.3.1C that prevents bootkits from working by establishing a boot chain of trust.
Totally free implementations also exist.

The only thing folks in Redmond may have a say is (when giving OEMs the Windows certification logo) asking them… something in exchange (*mandatory mob quote*).
Ie, in this case, systems must ship with SB enabled by default (and consequentially with microsoft public key that authorize what they have signed to boot).
That by no means excludes other keys from being added (say, Ubuntu, OEM, or user), nor is carved in the stone (see Q7 below).

Q2: Yeah, yeah, yeah: and what about all the fuss about having to ask (and pay!) them to have stuff boot?
A: Let’s first say that among all OEMs either your name is System76, or you sell Winstuff. And I think it’s not an understatement to say that at least 95% of computers sold fall into the latter category (which makes for SB enabled by default in almost 95% of PCs sold since 2012)
Now, imagine you want to use X OS (or EFI executable in general): either you disable SB or make it accepts this new stuff; and with every single user having full potential control over what they want to boot you might even call it a day (again, see Q7).
But what if you were a company with no time for reboots, tinkering and all? Or your grandma that’s already scared enough by a simple window?
… if only there was some approximately universal already trusted authority you could count on to like ‘subcontract’ and shift this signing burden…
Ohh, wait

Overconvoluted examples aside, for real: doing the public signing authority *for everyone* for free for all computers in the world is a task nobody else was up to.

Q3: EFI you say, yeah. Meanwhile I heard I’d also be required to sign drivers/modules. Secure Boot isn’t just about booting!
A: Well, technically once firmware has finished its stuff, and has handled the system to OS, SB itself has no further mean to work.
But at least in theory then, there would be nothing else stopping a rogue app with root access to modprobe kernel code to potentially achieve the same effects of whatever SB stands against.
Thus kernel (be Torvald’s or Bill’s) checks that “every component that can touch hardware is signed”.

Q4: But Linus once said he ain’t blowing any one
A: Putting aside that discussion never was about SB per se (but more about the tiny details to get aforementioned check properly do its job), nevertheless that work was merged a year later, with no ifs or buts

Q5: Ok, let’s assume that. But remember why I (or anybody for all that matters) should want to use it in the first place then? You mentioned some chain-ish thing.
A: Boot process is about a sequence of subsequent steps. Parent ones can always theoretically modify children without them (and a normal user) being aware.
And there’s indeed some malware that put itself before OS, for limitless power.

Secure Boot doesn’t prevent the malicious program from “installing” (i.e. messing up with your /boot partition or sector), but in the absence of a valid recognized trusted signature it will refuse to boot it.

Q6: But what about Windows RT potatoes tablets? They are Windows or bust!
A: Windows RT devices (RIP) were ARM devices, where

  1. basically no buyer of similar hardware usually give a ■■■■ about walled gardens, once kittens are watchable
  2. microsoft isn’t in the dominant market position even a fart would trouble antitrust

Regardless:

  • they are no more
  • anything newer even sold by microsoft itself is x86 and don’t indeed have these restrictions
  • microsoft itself is MANDATING every OEMs with Windows PCs to explicitly give MAXIMUM CONTROL to users
  • it looks like next MS’s ARMs computers-wannabe are going towards this direction too (aka W10 SoC edition, not to be confused with W10 mobile or IoT)

Q7: You put all that capital freedom bollocks. But meanwhile my damn laptop has no way to disable it.
A: Congratulations, you won the “I bought my PCs from a lazy OEM award”.
Jokes aside, we live in a free™ world, and OEMs stick to the minimum standard they can get away with.
In this case, managing to ship Windows (with the shiny sticker).
In the absence of an actual explicit “disabled” option, the other way to enforce it is clearing Keys database to trigger Custom Mode
How you’ll get there can range from easy to mindfuck, but hey, your complaints go to your vendor.

If you then want to still be able to securely boot Windows, make sure there’s at least a “restore default” option. Otherwise take a backup of MS PK.

You can then live forever with SB off ultimately, or if you want you can add your own certificate to take full and exclusive control of your PC.

Q8: Fine-ish, but I have heard that golden key leaked or something, and that seems bad, or nullifying, or whatevs
A: For starters, it’s not a key at all in the first place. It’s a ‘supplemental policy’ of Windows own bootmgfw.efi (first stage bootloader) that for a quite dumb slip with enough tinkering allows you to bypass aforementioned MS on ARM restrictions.
In other words, you are bypassing the diktat Microsoft enforced (among other things) with Secure Boot. But this is not affected at all, and it’s not less of a ‘backdoor’ than anybody that has physical access to the device already is.

Moreover it’s not even contingently affecting desktops.

Q9: But the NSA <\anything>…
A: But her emails Microsoft key is present in many computers to boot Windows.
Yes, it means your computer can boot their stuff, but it doesn’t give them more liberty than they’d already normally have by being your running OS.
I’ll stress again Q7: If undesired it can be removed at any time, once and forever.

Fun fact: Secure Boot prevented NSA own hacks from working.

Q10: But Stallman…
A: RMS gave his thumbs up to current state of affairs.

Q11: Oh come on? SB uses TPM, and everybody knows even the devil is better.
Actually… No, it doesn’t.
TPM is used to perform Measured Boot, which is a whole different thing.

Which, by the way -at least in its current implementation- is even blessed by RMS.

Bonus Q: But bloody Windows can tinker with my bios even when my BIOS is password protected!
A: If you are talking about boot order/settings, that’s simple efi design (thus also possible under linux)
Before having to write another Q&A: yes, some efi variables are exposed to live OS (there’s a whole filesystem just for that), but only trivial ones are modifiable.

3 Likes

I dunno whether it was mentioned before or not but anyway I guess I should share a link to a step-by-step and easy-to-understand guide I followed to create and enroll my own keys for SB. I hadn’t seen Arch wiki yet back in the days I messed with SB, so sorry for Gentoo wiki link (who cares? It’s Linux after all).

Also discussed here, if you read the post before the big wall of text

https://phoronix.com/scan.php?page=news_item&px=UEFI-SecureBoot-Lockdown-2018

1 Like

Totally unrelated?

Are people just mentally grep-ing articles for a string?

I do not own a computer with secure boot and dread the day I actually will be forced to buy one. You often tout Ubuntu as being visionary for implementing secure boot. Not having ever used secure boot I was caught off guard by some info I read on the Ubuntu forum recently. You seem to have left this minor detail out of your discussions on the secure boot topic. Apparently you have to disable secure boot to install some driver versions with secure boot enabled on Ubuntu. This extra level of hardware lockdown sounds neither convenient nor like an advancement to me. Here is the quote from the Ubuntu page on their forum:

“On some specific scenarios, installing the drivers, be it in offline mode through various DEB packages or through apt-get with internet access, will not work if Secure Boot is not disabled.”

“This is because the access needed is denied by Secure Boot so the drivers will look like they are installed correctly when in fact the did not. So for VERY specific cases, you will need to temporarily disable Secure Boot in order for the drivers to work.”

That’s Q3 from the FAQ.
The guy might not have mentioned the specific technical reasons, ifs and buts (because the point of the thread is different), but it’s nothing you/whoever couldn’t comfortably sign with their own keys.

This is not an advancement, M$ can stick their secure boot where the sun don’t shine. :-1:

2 Likes

Specific scenario example, NVIDIA proprietary drivers for Linux and Fedora. While Fedora can run with secureboot enabled as they have the necessary SHIM it will be blocked by secureboot after installing the NVIDIA driver instead of Nouveau.

I’m pretty sure that bigger vendors already have modules signed themselves. I think nvidia, but also vmware.

The problem (if somebody still hadn’t understood how drivers work in linux) arises when you need an external module outside official repos, and of smaller or shittier OEMs… but it’s no different in nature than signing the kernel.

p.s. shim just adds XX os key to the store, it’s not needed anymore afterwards

The post I referred to was about WiFi drivers. Big video card vendors may have the required keys, but I highly doubt all the smaller wifi card manufacturers do that.

Well, broadcom certainly isn’t, they are just shitty :grin:
Jokes aside, I’m not sure which part of the “you can sign it flawlessly just like anything else” you didn’t get.

Where “you” can mean you, or manjaro, or whoever you want your machine to trust.

1 Like

may be have a look here
https://www.phoronix.com/scan.php?page=news_item&px=Debian-10-Testing-Secure-Boot

1 Like

Thanks for promptness. I gave another nudge to arch releng team…
(which for anybody tuning in just now, yes, I know aren’t our upstream anymore as for iso, bootloaders, and stuff… still)

check this time in Debian
https://www.phoronix.com/scan.php?page=news_item&px=Debian-Installer-Buster-Alpha-5

Oh nice, step by step they realising that this thing is inevitable.
Meanwhile in Arch and Manjaro we have to create and enroll our own keys which is kind of hassle tbh.

RC candidate with secure boot
https://www.phoronix.com/scan.php?page=news_item&px=Debian-Installer-Buster-RC1

1 Like