[×]
You don't seem to be using an ad blocker.
Please consider installing one.
[×]
Now also available via Tor
http://iwccx6ebuapto7dlkd4m5fooud6nqn2z7go7aass5c4q6vl6gzs5htad.onion/
Einträge
-
Secure Boot Experiments
So, since I was bored recently, I somehow wanted to experiment with Secure Boot. I didn’t enable it when I bought my PC 10-ish years ago, not did I ever enable it for any of the Linux Distributions I tried out. So why now? Dunno, I was curious how well it works. So, this was mostly a “I have no idea what I’m doing, let’s see what happens” thing.
For most of the stuff, including basics, you wanna look at the references below. So, I guess this blog article is mostly a “things I stumbled upon / got confused about” list.
- Assumption: Enabling Secure Boot only makes sense if you also set a formerly “BIOS password” / protect the firmware setup with a password, otherwise someone with physical access to the machine could simply disable secure boot again? And even then… Surely there are ways to reset the settings including the password, in case you forget it? Wouldn’t secure boot be disabled by this, allowing an attacker to boot arbitrary stuff? (Well yes, but an attacker with physical access to the machine is not what SB was designed for, it’s for protecting against root kits. – Correct me if I’m wrong here).
- How do all these keys relate to each other, and what is the MOK? (See references below).
- Enabling Secure Boot in UEFI. What the heck is Custom or Standard key management? (Custom allows you to add your own keys? Or does it only influence the default keys? Your UEFI may vary.)
- What does “Secure Boot disabled / Setup mode” mean? (It means the keys needed for SB are not set up yet)
- Following the Arch Wiki article: Why the heck could I update the DB key
database using
efi-updatevar -a -c MS2.cer -k ../KEK/KEK.key -g "$(< ../myGUID.txt)" dbwithout entering the keys passphrase? (I was in setup mode. EFI variables in regard to SB keys can be written freely). - Why am I getting “Invalid Signature” by my UEFI, even though the binary is signed? (Either my UEFI implementation is broken, or this never works: The EFI binary had two signatures, I only added my signature to the Linux signature, instead of replacing it. Replacing works!)
- Why does stub complain about “0x1A Security Violation”? I clearly signed the binary with the MOK key? (The rEFInd binary didn’t have an .sbat section - the Debian package is too old).
- Does Debian actually auto-enroll the DKMS signing key into the MOK? If so, how? I thought this requires entering a password? (I would guess Debian does not auto-enroll, because it needs a password).
- Where does shim actually store “accepted” MOK keys? (I think in the efivars?).
- Why does shim use a light grey font on a light blue background? This is unreadable! (No idea).
References
- Secure Boot on Debian Wiki
- “Switching on Secure Boot in Debian” on blog.lazy-evaluation.net
- Secure Boot on Arch Wiki
- “The meaning of all the UEFI keys” on blog.hansenpartnership.com
- “Managing Secure Boot” in rEFInd docs
- “Controlling Secure Boot” in rEFInd docs
- “About UEFI Secure Boot” in Oracle docs