Slashdot Mirror
Microsoft Announces Project Mu, an Open-Source Release of the UEFI Core (betanews.com)
Mark Wilson writes: Microsoft has a new open source project -- Project Mu. This is the company's open-source release of the Unified Extensible Firmware Interface (UEFI) core which is currently used by Surface devices and Hyper-V. With the project, Microsoft hopes to make it easier to build scalable and serviceable firmware, and it embraces the idea of Firmware as a Service (FaaS). This allows for fast and efficient updating of firmware after release, with both security patches and performance-enhancing updates.
FaaS is something that Microsoft has already enabled on Surface, but the company realized that TianoCore -- the existing open-source implementation of UEFI -- was not optimized for rapid servicing. This is where Project Mu can help, the company says. "Mu is built around the idea that shipping and maintaining a UEFI product is an ongoing collaboration between numerous partners. For too long the industry has built products using a 'forking' model combined with copy/paste/rename and with each new product the maintenance burden grows to such a level that updates are near impossible due to cost and risk," the company said.
FaaS is something that Microsoft has already enabled on Surface, but the company realized that TianoCore -- the existing open-source implementation of UEFI -- was not optimized for rapid servicing. This is where Project Mu can help, the company says. "Mu is built around the idea that shipping and maintaining a UEFI product is an ongoing collaboration between numerous partners. For too long the industry has built products using a 'forking' model combined with copy/paste/rename and with each new product the maintenance burden grows to such a level that updates are near impossible due to cost and risk," the company said.
At least they took the name of a company that makes brake parts instead of another computer-related thing this time.
"When information is power, privacy is freedom" - Jah-Wren Ryel
Why? What possible reason do we need firmware as a service? Oh, I know. One more thing to generate recurring fees to fix the stuff that you already paid for. Plus the ability to plant stuff deep in your system when you aggravate the wrong people. Or how about exploitation by malicious parties? What a great idea.
it's just a spelling mistake, it was meant to read "open sores".
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
Comment removed based on user account deletion
Do you miss the good old days of keying in the bootstrap routine on start up?
“Common sense is not so common.” — Voltaire
Other than the wave of fancy graphics found on computer set-up screens, UEFI, has brought little to the table. As someone who has assembled over one-hundred computer, I think that the old BIOS, being a very minimal, compact, low-bug, text-based setup software was a idea better suited to reliable computers than "modern" bloated, bug-filled, UEFI.
Monopoly-wise, UEFI, has given Microsoft and unfair advantage to draw a circle around all (IBM Compatible) PCs and call them their own.
https://www.youtube.com/c/BrendaEM
Keying? Hrrmph! True freedom comes only from entering it with toggle switches!
Strange things are afoot at the Circle-K.
Open Source isn't as free as most people think it is.
Free and Open Specifications have far more value then Source Code does.
And No Open Source doesn't mean the specifications are Open automatically, There is a lot of ways to hide stuff in source code that would make comprehending the logic far more complex then just a normal reverse engineering of it. There is also a lot of system particular calls which may be the case as well.
For example a lot of old Legacy Applications will save data files by just dumping the memory structure into the file in raw binary format. I can take this code it will compile and work on a different platform but wouldn't be able to read the data files, Because how the system handled memory was different (such a using Big Endian vs Little Endian which is more common today) or just how an integer may be classified 16bit, 32bit, 64bit....
Open Source alone doesn't make it free or open. It just gives you the source code, which you may be able to alter some features without having to do a full rewrite.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
I'd prefer my firmware updates to be as soulless as possible thank you
Please mod this up.
I have no idea what you guys are talking about.
http://progressquest.com/spoltog.php?name=Son+Of+Son+Of+DarkRookie
Toggle switches, my god are you lazy! A true electron cowboy configures the boot sequence via jumper wires!
Legacy is hard on closed or open, but at least with open there's a place to start. And thankfully CPU's uses to be slower, so emulation of the whole system isn't a terrible option.
You already can't write your own firmware for these devices due to signing requirements. At least being able to audit a common codebase is a step up.
No sir! A true expert bootstraps by cutting the appropriate diodes out of the diode array with a wire cutter! You only have to do it once!
You bought your computer from Microsoft, what did you except?
Though if other OEM's followed suit, it might be interesting.
UEFI is a replacement for the "beloved" BIOS, that's there in firmware, before your system boots.
It's been on *EVERY* workstation and server for years.
M$ tried to lock in Windows by making "secure boot" with UEFI... and only they had the cryptographic signing that was accepted. That didn't fly very long....
And for anyone who thinks "firmware as a service" is a good idea, instead of running away screaming, here, let me hijack your system, and install my own firmware on your system....
Open Source isn't as free as most people think it is. Free and Open Specifications have far more value then Source Code does. (...) For example a lot of old Legacy Applications will save data files by just dumping the memory structure into the file in raw binary format.
And how many of those applications do you think have specifications that are actually current, correct and complete? Specifications are vital if you're trying to establish a standard. If you're trying to decipher a one-of-a-kind format created by proprietary software, custom-developed code or anything like that the source code is in 99.9% of the cases the only answer to what is really happening. Then you start looking through version control systems (if you're lucky), design docs, bug reports, ask the business users etc. to reverse engineer why it's happening. Sometimes we figure it out, sometimes it's still valid but often it's a solution to a problem we don't have anymore. Other times it's simply a bug or it does things differently that the users thought it did. And sometimes nobody can figure it out and you're told to just replicate it, warts and all. So if there's ever a choice between an implementation and a spec, I'll take the implementation any day.
That aside, almost any proper specification today ought to have a reference implementation and a compliance test suite both of which is code. So in order from best to worst I'd say it's:
1. Spec + code
2. Code
3. Spec
4. Binary
Unless it's a very known spec with lots of implementations and you just happen to be the 3142th FTP client ever written. But in that case get your head out of your ass and use a library. One implementation is bad but there's very few standards that benefit from more than say ten, then they're writing to the spec because the encoder x decoder or server x client matrix is too unmanageable for anything else.
Live today, because you never know what tomorrow brings
Mercy me! You win.
I assumed keying was the right verb for using any kind of switch. For what it's worth, in my head I was thinking of the front panel toggles on a minicomputer.
Once we had magnetic drums and terminals with paper tape things got a lot easier. Not better, but easier. But it did mean we could raid the bit bucket for an unlimited supply of confetti.
“Common sense is not so common.” — Voltaire
I fully agree with Microsoft that UEFI has a forking problem. But that is caused by the fact that BIOS vendors take tianocore as a baseline and extend it. The root of the issue is that tianocore itself does not provide a complete UEFI firmware implementation, it gets about 40% of the way there and expects the Silicon vendors (Intel, AMD, NVidia, Qualcomm, etc.) and BIOS vendors (AMI, Phoenix, Insyde, Biosoft, etc.) to fill in the rest with proprietary code. This problem is actually almost identical to the Android fragmentation problem. But really what Microsoft has done here is create another fork for their Surface products.
The good thing is that Microsoft has open sourced a lot of that fork and have pushed the percentage forward from 40% to maybe 50 or 60%. If you look at what they have released though it is very customized for Surface... they have come up with their own answers for a lot of stuff that the UEFI specification already has answers for; the BIOS setup menu/HII database being the most notable. The percentage gained could be much higher if they didn't insist on duplicating code already in tianocore just because they think they know better. Separately, the tianocore guys are also trying to solve the fragmentation problem. A complete open source UEFI firmware implementation is under development right now: https://github.com/tianocore/edk2-platforms/tree/devel-MinPlatform I am one of the active contributors to tianocore. It is my hope that if Microsoft is truly interested in trying to solve the fragmentation problem that they are willing to work with tianocore and contribute to it instead of building their own competing open source community.
The one thing that all of us should keep an eye on is the potential for a Microsoft attempt to use the Windows Hardware Compatibility Program to force every PC on the planet to use MU. Creating a firmware mono-culture would give Microsoft much more control over the PC industry than Windows itself already affords them. They could turn every PC into nothing more than a Surface with a different OEM logo on the lid. It's certainly one way of solving UEFI's forking issue, but it would significantly strengthen the walled garden they are trying to build with Windows 10 at the same time.
ACs on Slashdot in 1998: ... Saying stupid shit
... Still saying stupid shit
ACs on Slashdot in 2018:
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
Has anyone actually gotten anything from EFI but pain? Anything that would justify the whole new debacle rather than just an update to the old BIOS to understand bigger drives?
I'm putting my money on Toilets as a Service, TaaS.
The only appropriate response to proposing firmware as a service.
Editor, A1-AAA AmeriCaptions
Nope. I want all my firmware to be in OTP (one time programmable) hardware chips, in sockets, that have to be physically changed out to upgrade firmware, so jackass companies can't brick devices with shitty 'upgrades', and if they give me a bad upgrade anyway, I can just go back to the old OTP ROM.
Exactly. Firmware is what's permanently flashed into your hardware to make it run, it's not a service, and if it was a service any availability issue would mean your hardware wouldn't work any more. Sheesh, what's next, DRAM as a Service? PSUs as a Service? Wall Socket as a Service?
I started to have a look, mostly to see how many new UEFI security holes I could spot in the first five minutes. Holy fuck, have you seen the size of that code base? There's an entire OS and supporting services hiding in there screaming to get out (and waiting to be exploited), the bloat is ridiculous. I stopped skimming after I don't know how many thousand lines of code, and I'd barely scratched the surface.
They'd have to reopen Bug #1