Project Mu is mostly about getting the messy parts of the UEFI ecosystem sorted out: Instead of hoping that IBVs ("Independent BIOS Vendors") clean up their act (because, to be frank, they don't), they get ready-to-use components that Microsoft is using itself on the Surface products and provide a certain baseline standard (security, UX, ...).
The difficult part about firmware in general (hardware initialization) is still under lock and wrap though: you'll have to get it from the silicon vendors and link it with the open EDK2/Tianocore (which is the UEFI base) and Mu (which is a toolset to extend that base) components to a full firmware image. In particular, those components aren't distributed as part of EDK2 or Mu.
Nothing can change the fact. HW vendors doesn't want to release the part of CPU bootcode directly. The most end-users wont care about the initialization detail but just want a working hardware product. Unfortunately, the hardware vendor never compromise and buyers won't have too much consideration about that as they are just selling products for the hardware vendor.
So they have to execute their plan B to bear another ecosystem. But it's hard to tell about how much difference between of them.
Indeed. BIOS isn't perfect but it's small and simple and provides enough to boot an OS, whereas UEFI looks more like an attempt to create another OS to run before the main one. It's a great example of design-by-committee and second-system-syndrome.
This is potentially an alternative to Coreboot for open source firmware. AFAIK it's used in Microsoft Surface PCs and it looks more consumer-friendly with menus and such. The downside is that it's based on TianoCore which is reported to be very poor quality.
Project Mu, like EDK2/Tianocore lacks everything coreboot has - and vice-versa: coreboot doesn't care too much about OS-side or user interfaces but delegates that to something we call "payload".
EDK2/Tianocore on the other hand (and Mu, by extension) is extremely weak in the actual hardware initialization department because they only care about OS-side and user interface matters.
If you dig a lot, you'll find one memory init driver there (for the now-dead Quark SoC).
Project Mu is an attempt to make something reasonable out of EDK2, and I commend them for it (EDK2 _really_ needs an effort like this).
But to get a useful (UEFI style) firmware image without signing NDAs (and not the ordinary NDA, the more secret ones) you'll need to combine Project Mu with... coreboot.
here we go again, every thread, same confused comments…
Coreboot is just an early stage bootloader that does basic bringup and jumps into a payload… like… TianoCore EDK2 :) Comparing Coreboot with something that can be its payload does not make much sense.
EDK2 does have some PEI code but it's not very interesting. The valuable part is the DXE phase and beyond.
If I were to build a "modern device", UEFI would be the last thing I'd want to put on it. I don't want to worry about exploits below ring 0 with a proprietary mess of binary blobs that lock me out of my own hardware.
Except for the parts in SMM (often considered "ring -2", below virtualization) that are installed by UEFI to implement stuff like Authenticated Variables (the thing that makes UEFI Secure Boot work and requires a rather complete crypto library for it). See https://firmware.intel.com/sites/default/files/resources/A_T...
That's not really UEFI though per se. Having an oracle in SMM is one option, but sticking them in the Management Engine/PSP or an expanded TPM are other options.
And SMM is way older that UEFI. We'll almost certainly still have SMM after UEFI is gone.
> That's not really UEFI though per se. Having an oracle in SMM is one option, but sticking them in the Management Engine/PSP or an expanded TPM are other options.
It's UEFI code that's linked into a separate module. But it's the same code architecture (and largely the same code), just running in a different CPU mode.
> And SMM is way older that UEFI. We'll almost certainly still have SMM after UEFI is gone.
There are experiments at hardware vendors to get rid of SMM. While that will take approximately as long as the age-old attempts to retire legacy PC components (such as the RTC), it's not universally loved by vendors anymore.
I mean, the management engine these days is the same code architecture, also loaded by UEFI. Is it the same thing?
And yeah I'm sure places like Google that control the whole stack have the ability and will to get rid of SMM for their own systems but that doesn't make sense for the vast majority of systems, particularly from white box vendors. As an example, new archs like AArch64 and RISC-V have equivalents in EL3/PSCI and Monitor Mode (mandated in all chips) respectively. The concept of a piece of code shipped by your board vendor running under the OS and hypervisor for system management tasks is just too useful of a concept.
The Management Engine is very a different beast, if only because its code runs long before the main x86 CPU is even started (and UEFI can run). It also seems to run Minix these days (and before they moved the ME to the tiny Quark-style x86 core, some RTOS on an ARC core).
Unlike the ME firmware, SMM code is usually built with, shipped with and loaded by the x86 firmware.
Pardon the interruption, but I know what all these term are (UEFI, ME, SMM) on a very cursory level, but this thread is sparking g my curiosity. Do you know of any good books / websites / etc. That docs good job of explaining how all these pieces work together in modern processors and firmware?
Perhaps I'm missing something but isn't the RTC still used for time keeping when the computer is powered off? Legacy? Perhaps - but I don't know that there is a 1:1 replacement on PCs?
Actually, "modern device" seems to mean "locked-down anti-user anti-backwards-compatibility walled garden" more than anything else, so I'd say the term is quite accurate. ;-)
To expand on this, if successful, this project would basically make it a lot easier to get firmware updates and write firmware for more devices. This, in conjunction with the Linux Vendor Firmware Project, could potentially make it extremely easy for vendors to support Linux and get firmware updates via Linux. Whether that's the projects actual goal or not, I am not sure, but that's what opportunity a project like this potentially avails us to.
It doesn't address the problem of binary blobs of platform initialization, the most important part of booting anyway. UEFI is just a glue, modern 64bit DOS, so can be dropped completely. Improving coreboot would have been a saner approach.
The difficult part about firmware in general (hardware initialization) is still under lock and wrap though: you'll have to get it from the silicon vendors and link it with the open EDK2/Tianocore (which is the UEFI base) and Mu (which is a toolset to extend that base) components to a full firmware image. In particular, those components aren't distributed as part of EDK2 or Mu.