[kr99x]

The only firmware code running after boot that UEFI mandates is not below ring 0 and is fully optional - called only if and when the OS asks for it. The UEFI runtime services table is not a kernel and is parked in ordinary memory waiting to be jumped to/called.

SMM is supported but not mandated, which is exactly how any hardware feature should be treated. Blame those enabling the SMM code you don't like. Or blame the hardware manufacturer for putting the feature in at all.

UEFI is not your enemy. Its only sin is being overly complicated, which is (somewhat) debatable given the complexity of systems and OSes needing to be bootable.

[nixpulvis]

so... as I see it the argument is that simply allowing the features is a "flaw" in the design, since, essentially, companies can't be trusted to do the right thing?

As a tinker I'd like to install my own boot code, disable default features and all that (I do some of it already), I fear it's still far from the norm.

I guess "my" question is, what features am I missing and are there better ways to get them without being so intrusive?

[kr99x]

The intrusive parts that you see in a lot of firmware today fall into two categories.

One is like Intel ME. It supports use cases you as an end user do not give one single damn about and could easily do without, if given the option. Clean and remove as much as possible with no remorse.

The other is like SMM. Believe it or not, it's only accidentally the intrusive and insecure monster it has become. The point was exactly what it says on the tin. System Management Mode. The OS would ask the 'system' to do something it didn't know how to do, like change some power configuration in a laptop, and the firmware would handle it and then give control back. But these operations were delicate and needed to not be interrupted. And the hardware involved was delicate and needed to not be touched in the wrong way, lest the system hang or even fry. So it was locked away where the OS couldn't touch it. And then people started noticing they could use an untouchable special execution mode in other ways, and, well, here we are. The unfortunate thing is that because of how it started, you would feel some pain on most systems today trying to get rid of it. Your OS does not have drivers to change the CPU thermal characteristics properly and in accordance with silicon design (because the vendor did not develop one or make the information available to the outside world). So removing SMM will make many 'nice' features stop working. You may lose the ability to suspend and resume. Your power draw may be stuck too high or too low. It's possible on some systems you would be fine, but on others not so much.

Like the people demanding that graphics vendors provide open source drivers rather than binary blobs in the hope of making things better, really what's needed here is advocates pushing for the tasks performed in SMM today to be migrated to OS drivers, and from there to open source drivers.

You as a single tinker today aren't likely to get all this stuff working with the non-existent documentation.

Blame the silicon vendor for doing things in the most scary, back-door-ish way possible. UEFI didn't make them do that. The same crappy business practices that drive all bad proprietary software decisions did.

[xvilka]

It is because the UEFI standard was designed to give the vendors such freedom. The only way to make vendors do the sensible things is to force them with a strict standard as possible, defining almost everything about openness and security. Even in this case there will be vendors who: 1) can't read the specification 2) do the thing their own way 3) obfuscate code for the sake of obfuscation 4) write the code the worst way possible.

[nixpulvis]

Great points.

I'd expect those in charge of maintaining and actually implementing these things for customers would also be aware. Project MU seems like at least in many ways a step in the right direction from Microsoft.

OS drivers seems ideal as long as it's open source, otherwise I'd expect Linux (or other OSes) hardware support to suffer.

Also interestingly, on the topic of sleep state. I have a Lenovo Thinkpad X1 Carbon (6th edition) and it's sleep was broken (and still partially broken) because Lenovo only implemented the new S0 low power idle "Modern Standby" (what a name!), without implementing the S3 mode as well. Sigh...

[yaantc]

> I have a Lenovo Thinkpad X1 Carbon (6th edition) and it's sleep was broken (and still

> partially broken) because Lenovo only implemented the new S0 low power idle "Modern

> Standby" (what a name!), without implementing the S3 mode as well.

Good news: please update your firmware, and you will gain the option to either use this new S0 mode (for Windows) or the S3 mode (for Linux) in the firmware. This is not perfect if you're dual booting, but if you're only running Linux it solves the issue.

Also, you can now update your firmware from Linux using fwupdmgr. Be aware there's a Lenovo bug if you're dual booting: you'll end directly on Windows after an update. So keep a Refind USB key around, use it to boot Linux, and reinstall EFI grub. If you're pure Linux, no such problem.