Intel OEM Private Key Leak: A Blow to UEFI Secure Boot Security

The pervasiveness of secure boot has genuinely made things difficult for attackers - there'd have been no reason for the Black Lotus bootkit to jump through all the hoops it did if it weren't for secure boot, and the implementation of UEFI secure boot does make it possible to remediate in a way that wouldn't be the case without it.

But secure boot at the OS level (in the PC world, at least) is basically guaranteed to give users the ability to enable or disable it, change the policy to something that uses their own keys, and ensure that the system runs the software they want. When applied to firmware, that's not the case - if Boot Guard (or AMD's equivalent, Platform Secure Boot) is enabled, you don't get to replace your firmware with code you control. There's still a threat here (we've seen firmware-level attacks for pre-Boot Guard systems), but the question is whether the security benefit is worth the loss of freedom. I wrote about this a while back (https://mjg59.dreamwidth.org/58424.html) but I lean towards thinking that in most cases the defaults are bad, and if users want to lock themselves into only using vendor firmware that's something that users should be able to opt into.

Would it be sensible to make that choice using a good old fashioned jumper? For example, when the jumper is connected to pins 1 and 2, the firmware must be signed by a list of vendor-controlled keys; when the jumper is connected to pins 2 and 3, the firmware must be signed by a list of user-managed keys. That way, I can choose what kind of freedom makes sense for me. Most people value the freedom of not having to worry about firmware, while others value the freedom to use or create their own firmware.