Uefi Shell Vulnerabilities Allow Attackers to Bypass Secure Boot

And if it's security focussed, I think it's acceptable to say "It's AM4 (not 5), and only works with this RAM brand with these times and costs 5 times as much". It's a niche, and when people are into a niche they take the tradeoffs they get.

This is seriously the least likely way for you to be hacked. Much more likely is that an auto-update is downloaded and run from a hacked server, or you sometimes use pip/npm/etc to install dependencies for some software project and get malware that way, or you get tricked into opening a zipped document in an email that ends up having executable code because industry-standard doc viewers and OSes try to be too smart ...

> Secure boot never stopped me from doing anything I wanted with my hardware.

But, you may have done a lot of things that it should have stopped you from doing. For 5 to 10 years a bunch of utilites for monitoring temperatures and fan speeds and controlling RGB lighting etc have used the signed "winring0" driver to be able to poke arbitrary hardware registers of various chips over various low-level busses (i2c etc), just a couple months ago this "winring0" driver was blacklisted, identified as malware, and quarantined by Windows Defender. There's other solutions that these tools have shifted to, like "PawnIO" and custom signed drivers.

On the topic of Framework, you can use "ectool" to control fan behavior and charging behavior etc of the environmental controller chip, but for many years you had to disable secure-boot for this thing to be able to poke that chip. About a year ago I recall a forum conversation where someone was intent on porting this tool to use winring0 on windows so that they did not have to "endanger" their system by disabling secure-boot. I really didn't think there was any point, because if winring0 lets you bypass protections that secure-boot relies on, it's just a big charade.

Many signed third-party windows drivers have been found vulnerable to enabling arbitrary memory poking somehow, which theoretically lets you bypass any protections that secure-boot intends to provide. They eventually get updated and old versions blacklisted, but there's always a bunch and there's always more. And remember Logo-Fail? Letting people update the boot logo, without re-signing with their own key loaded into their system?

And if we look at the other discoveries by Eclypsium, the theme here is debug and repair tools. Do you want debug and repair tools to be allowed without disabling secure-boot?

It turns out that lots of people, maybe most people, expect to be able to do things with their laptop, which secure-boot really shouldn't allow. For practical reasons we tend to just go ahead and get that signed with some Microsoft key and allow it. There's a real theater to thinking secure-boot is super important and you're super-secure, while expecting and depending on functionality which really means that secure-boot has been compromised in 100 different ways. I just turn it off, it just makes things more complicated.

Physical access ? Like putting an oscilloscope on your cpu bus ?

Citation needed. /s

You do realize that Secure boot is mostly pushed by Microsoft, which has a terrible security.