Comment by nixpulvis
7 years ago
Reading up on Project MU now, and I'm sorry, what is this about firmware as a service? This seems like exactly what I don't want. XaaS (X as a Service) is great when there's something external that is only temporarily or optionally required, (or too expensive). Otherwise it's an ongoing dependency. But with firmware, once I own the hardware, I should own the firmware too.
Without knowing more about this specific Firmware as a Service I can only imagine how this will actually look. Maybe it just means that updates are automatic? Even that alone is an interesting debate.
Otherwise, Prohect MU looks like a modern wrapper around UEFI, what's being done to address the fundamental issues? Firmware code running after boot, modifications to firmware possible by changing code between boots, etc...
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.
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?
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.
3 replies →
Yeah I agree- firmware as a service doesn't exactly capture what Project Mu is trying to do. But the point is, firmware should be easy to update as any service rather than some huge monolithic codebase that was forked the master (TianoCore) and then hammered on until the platform booted.
In a perfect world a product would ship with perfect bug free and secure firmware and it would never need updates. And ideally, manufactures would allow for users to more easily install their own UEFI/firmware onto their device but that brings in some added challenges of security.
Since developers make mistakes, updates are currently the best solution we have. Making those updates more affordable to service, making the changes transparent to the end-users via OSS, and making it easier to apply those updates are all things Project Mu is trying to accomplish.