5 ms·

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 UE

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/ 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).

nixpulvis 7y 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...
- kr99x 7y ago
  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 7y ago
    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 7y ago
      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.
- matthewfcarlson 7y ago
  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.
OJFord 7y ago
Disclosure. You're exactly _not_ disclaiming. :)
kr99x 7y ago
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.
tenebrisalietum 7y ago
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.
pabs3 7y ago
Why did Microsoft fork TianoCore into Project MU instead of contributing directly upstream to the TianoCore project?

nixpulvis 7y 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...

kr99x 7y ago
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 7y ago
  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 7y ago
    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.
matthewfcarlson 7y ago
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.

OJFord 7y ago

Disclosure. You're exactly _not_ disclaiming. :)

kr99x 7y ago

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.

tenebrisalietum 7y ago

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.

pabs3 7y ago

Why did Microsoft fork TianoCore into Project MU instead of contributing directly upstream to the TianoCore project?