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

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

Board footer