Secure Boot and opROM

d.ALT · 2024-12-18 09:19:20

Rod Smith wrote:

(https://www.rodsbooks.com/efi-bootloade … ng-sb.html)
Taking control of your computer's Secure Boot keys offers several advantages over these approaches:
Locking out threats from the standard keys—In theory, Secure Boot should prevent malware from running. On the other hand, it's always possible that an attacker could trick Microsoft into signing malware; or signed software could have bugs, such as the Boot Hole bug discovered in 2020 and described later, in Revoking Keys and Hashes. If you use Shim with the default keys, your computer will remain vulnerable to these threats, at least until they're discovered and your blacklist database is updated.
Locking out threats from your distribution's keys—Similar to the preceding, it's also possible that your distribution's keys could be compromised, in which case an attacker could distribute malware signed with the compromised keys. Depending on how you manage your keys, you can greatly reduce this vulnerability—but the greatest level of protection will require extra effort on your part.
Eliminating the need for MOKs—The Shim and PreLoader tools both rely on Machine Owner Keys (MOKs), which are similar to Secure Boot keys but easier to install. Because they can be more easily installed, it's conceivable that they could be more readily abused by social engineering or other means. Eliminating MOKs may therefore slightly increase your security, particularly if you're managing a collection of desktop computers used by other people.
Taking philosophical control—Relying on a third party's keys strikes some people as being wrong. Partly this is because of the preceding reasons, but some people object to the dependency on a more philosophical level. If you fall into this category, generating and using your own keys may be appealing.
Testing and development—If you want to develop your own boot manager, you may need to be able to test a signed version of your software in an environment that mimics a "stock" computer. The process for signing binaries with Microsoft's Secure Boot keys is tedious and time-consuming, though, so you may need to set your computer up with your own keys so that you can sign the binaries yourself. When the software works as you expect, you can send it to Microsoft to be signed.
Enabling Secure Boot on systems without keys—Some servers ship without Microsoft's Secure Boot keys installed. Using Secure Boot with such a server requires adding keys as described on this page. Note that Linux distributions for exotic platforms, such as ARM64, have acquired signed Shim implementations only relatively recently—Ubuntu 20.04 ships with a signed ARM64 Shim, for instance, but Ubuntu 18.04 does not. Thus, you may need to take this approach if you want to use Secure Boot with some exotic hardware.
Overcoming boot coups—This one is admittedly speculative. Some people have reported difficulty getting their computers to boot anything but Windows by default; they can boot to Linux temporarily, use efibootmgr to set Linux as the default boot loader, but then find themselves booting back to Windows because the firmware keeps setting Windows as the default. If the Linux boot entry remains in place but is "demoted," setting your own boot keys might enable you to control this problem by removing Microsoft's key from the regular Secure Boot list and adding it to your MOK list. You'd need to use Shim or PreLoader for this to work. Note, however, that some computers hang upon encountering the first Secure Boot error; and if the problem is caused by a computer "forgetting" its entire boot list, this solution will do no good whatsoever.

(emphasis mine)

ArchWiki wrote:

(https://wiki.archlinux.org/title/Unifie … r_own_keys)
3.1 Using your own keys
Warning: Replacing the platform keys with your own can end up bricking hardware on some machines, including laptops, making it impossible to get into the firmware settings to rectify the situation. This is due to the fact that some device (e.g GPU) firmware (OpROMs), that get executed during boot, are signed using Microsoft 3rd Party UEFI CA certificate or vendor certificates. This is the case in many Lenovo Thinkpad X, P and T series laptops which uses the Lenovo CA certificate to sign UEFI applications and firmwares.

And also:

--- ---

~~Are we, as *Linux users, somewhat "defeated" by opROM?~~
In case someone wants to take... "advantage"... of Secure Boot, are we, as *Linux users, somewhat "defeated" by opROM?
How do you fell about (not) taking full control by enrolling your own personal kerys?
To those of you who use Secure Boot: how do you deal with standard (Microsoft) keys and opROM?

Last edited by d.ALT (2024-12-18 10:57:35)

Head_on_a_Stick · 2024-12-18 10:27:34

I use my own keys and purge the Microsoft versions. I have two ThinkPads (E485 & P14s), neither seem to use opROMs so I suppose I'm lucky in that respect.

d.ALT wrote:

Are we, as *Linux users, somewhat "defeated" by opROM?

Not really, disabling SecureBoot is always an option. Or use the shim, as Fedora et al do.

d.ALT · 2024-12-18 11:00:08

Head_on_a_Stick wrote:

d.ALT wrote:
Are we, as *Linux users, somewhat "defeated" by opROM?
Not really, disabling SecureBoot is always an option. Or use the shim, as Fedora et al do.

I'm Sorry... You misunderstood because I asked the question the wrong way, my bad!!! I edited it.

Head_on_a_Stick · 2024-12-19 17:28:35

Anything that targets opROMs would likely be a nation-state effort. The answer to that problem is to move beyond nation-states and towards a system of Democratic Confederalism, as practised in Chiapas and the Democratic Autonomous Administration of North & East Syria. I don't think SecureBoot can help with that

LarryDave · 2025-12-10 20:04:33

This is beyond stupid.

I just spent a good few hours reading the wiki and finally ditching systemd-boot, creating a UKI and adding it directly to the UEFI with efibootmgr. I was excited to also sign the UKI with my own keys and enable Secure Boot.

Come to find out I can't do that because of my GPU.

$ find /sys/devices/ -name rom

/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/0000:02:00.0/0000:03:00.0/rom

$ lspci -s 03:00.0

03:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Navi 44 [Radeon RX 9060 XT] (rev c0)

But now that plan went down the drain. It got 1000x more complicated.

https://wiki.archlinux.org/title/Unifie … _signature

Gotta follow that one but I can't compile edk2 BaseTools. It errors out.

Even if I did pass that step, I don't know if in the end it'll work. It only lists determining the OpROM, not signing it or how.

d.ALT wrote:

How do you fell about (not) taking full control by enrolling your own personal keys?

I feel angry.

ReDress · 2025-12-11 08:05:09

Head_on_a_Stick wrote:

Anything that targets opROMs would likely be a nation-state effort.

Based on my little experience using computers, I.would *like* to imagine that this is not very uncommon.

cryptearth · 2025-12-11 16:35:05

let's face the truth: secure boot is broken by design: it only protects the boot - but as soon as you're on user land and can execute arbitrary code the cardhouse collapses
microsofts driver signing is the only thing that's halfway usefull - although it causes issue on the other side when using developement hardware not having a proper signed driver yet

only if you lock down the entire os so that only signed code can be executed and that even these settings are somehow signed themselfs - so basically a kiosk-mode - only then secureboot makes sense

why? because the moment i can run arbitrary code i can run code which completely defeats the entire chain down to the PK

plus: it comes with all the issues and downsides it can because it's a microsoft invention for win8 to get a new eeal to earn by new hardware sold - same as with win11 - and same as back in the days of ibm pc and basic
microsoft is based on this idea and they keep on it 40 years later

another reason to ditch everything from them
you want secure boot: start by replacing both your vendor uefi and the firmware of your devices with oss alternatives - good luck finding hardware even supporting this idea

Arch Linux

#1 2024-12-18 09:19:20

Secure Boot and opROM

#2 2024-12-18 10:27:34

Re: Secure Boot and opROM

#3 2024-12-18 11:00:08

Re: Secure Boot and opROM

#4 2024-12-19 17:28:35

Re: Secure Boot and opROM

#5 2025-12-10 20:04:33

Re: Secure Boot and opROM

#6 2025-12-11 08:05:09

Re: Secure Boot and opROM

#7 2025-12-11 16:35:05

Re: Secure Boot and opROM

Board footer