Comment by matthewfcarlson
7 years ago
I agree- this is a very PC focused article but firmware is everywhere. It needs to be updateable and making it open makes it far easier to update.
As far as UEFI goes, I'd just like to point out Microsoft's open source Firmware efforts (Project Mu). https://microsoft.github.io/mu/ The goal is to make firmware easier to service and easier to update with security fixes for older projects.
While it's not perfect, it is a great step forward. I think we need to see more of this in the future from other companies.
(Disclaimer: I work for Microsoft and contribute to Project MU).
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?
4 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.
IIRC Microsoft was instrumental with a few other companies in developing the rather arcane and overbearing ACPI standard in the 90's that continues to make it difficult for non-Windows operating systems to reliably work with a laptop's hardware even today.
I've played with U-Boot on ARM platforms. It's a breath of fresh air. It loads the OS and then just gets out of the way. This is what simplified PC firmware should be.
While there's a lot of MU I could take or leave and some I don't really see the value of, I greatly enjoy that there's finally at least one effort out there to wrangle the build system. Having not used MU's build yet, I can't say if you've succeeded, but I applaud the effort since current "standard" build processes and scripts and wrappers in use are.... not good.
Disclosure. You're exactly _not_ disclaiming. :)
Why did Microsoft fork TianoCore into Project MU instead of contributing directly upstream to the TianoCore project?