Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Microsoft IT

Microsoft Announces Project Mu, an Open-Source Release of the UEFI Core (betanews.com) 121

Posted by msmash from the good-samaritan dept.
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.
This discussion has been archived. No new comments can be posted.

Microsoft Announces Project Mu, an Open-Source Release of the UEFI Core More

Microsoft Announces Project Mu, an Open-Source Release of the UEFI Core

Comments Filter:
  • So we can lock you in and not fix our shit
    Why would we. We have your money and your balls.

  • At least they took the name of a company that makes brake parts instead of another computer-related thing this time.

  • Firmware as a service? (Score:1)

    by Anonymous Coward

    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.

    • If you have an ecosystem with a wide variety of hardware it might be simpler to manage. Not sure, I only just heard of this so i can't come to a conclusion if its a good product or not
  • Comment removed based on user account deletion

  • Not a Fan of UEFI (Score:3, Insightful)

    by BrendaEM ( 871664 ) on Thursday December 20, 2018 @10:58AM (#57836394) Homepage

    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.

    • Re: (Score:2)

      by JBMcB ( 73720 )

      Monopoly-wise, UEFI, has given Microsoft and unfair advantage to draw a circle around all (IBM Compatible) PCs and call them their own.

      In what way? Pretty much every other x86-based OS can boot off of UEFI.

      https://en.wikipedia.org/wiki/... [wikipedia.org]

      • Re: (Score:1)

        by Anonymous Coward

        Because they all need to petition redmond for a signature with the redmond key to be somewhat viable as a competitor to redmond. And, of course, it means supporting lots of redmond tech (fatshame32) just so you can boot. BIOS is crappy but so much simpler to deal with, that UEFI is not an improvement.

        • Re: (Score:3)

          by bws111 ( 1216812 )

          Bullshit. We have our Linux images signed with our own key, and they work just fine. There is zero Microsoft involvement. FAT is 'lots of redmond tech'?

        • Not true, quite a few computers, especially server and business grade allow a physically present user enter platform setup mode and upload the public portion of the PEK and then you can sign any KEK that you like.

          • IF you add your own KEK, you can sign any bootloader, driver, or kernel that you'd like to use.

          • Re: (Score:2)

            by Rob Y. ( 110975 )

            That may be technically true, but I think the original poster was mainly referring to off-the-shelf desktop computers, which come with only the Microsoft keys - and for which typical (and even fairly technical) desktop Linux users need to deal with a Microsoft-sanctioned shim to get a working installation (or disable encryption altogether - if the BIOS in question allows that).

            I guess the bottom line question is - if an MS Surface does not allow you to install Linux on it, should we be wary of other boxes s

            • You can install any Linux that uses the shim, or you can install your own KEK key. I not sure if you can take control of the PEK though and entirely block microsoft software from the device though. https://docs.microsoft.com/en-... [microsoft.com]. But the suface is largely business class, having a TPM that you can use to verify the boot chain.

              All in all replacing consumer firmware with mu, may actually provide more control on average, giving more options than such M$ key on or secure boot off.

              • Also having one codebase to pressure to enable PEK setup is still a better situation than trying to tie OEM's down on a thousand different codebases.

            • I guess the bottom line question is - if an MS Surface does not allow you to install Linux on it, should we be wary of other boxes starting to use its UEFI implementation?

              But they do, they always have. Despite all the fear-mongering over the years of how SecureBoot will kill Linux on the desktop.

              You can add your own keys (if the OEM adds that feature), you can turn SecureBoot off altogether or you can use the shim. Even then that all only applies to hardware that has gone through the "Certified for Windows 10" program.

          • Not true, quite a few computers, especially server and business grade allow a physically present user enter platform setup mode and upload the public portion of the PEK and then you can sign any KEK that you like.

            Any OEM machine that ships with Windows is required to allow a physically present user to install their own key. The only OEM that can get around this? Microsoft. They do not follow that rule with the Surface, as an example. At least not the ARM ones. I don’t know what they do with the x86 ones.

            • ARM's always been an exception unfortunately, and the whole embedded space is a mess generally.

              • ARM's always been an exception unfortunately, and the whole embedded space is a mess generally.

                True. It's a lot easier to use non UEFI firmware with ARM, though. In fact, it is rarely used on ARM. AFAIK the only phone manufacturer to use UEFI is Apple, but I could be wrong. Though in the ARM server world there is a lot more UEFI firmware. If you have a very limited set of hardware requirements, CoreBoot is probably a better choice. But if you need to support expansion slots and a very configurable boot process then UEFI is way more mature. I know the Siemens uses CoreBoot to load up Intel base

        • Re: (Score:2)

          by JBMcB ( 73720 )

          Because they all need to petition redmond for a signature with the redmond key to be somewhat viable as a competitor to redmond.

          That's *ONLY* if you get a machine with secure-boot enabled by default and Windows pre-installed, and even then it's only a couple of manufacturers that only include Microsoft keys. I think it was only a *requirement* on WinRT devices, which are now dead and buried. My MSI motherboard from four years ago lets you add keys to UEFI to enable secure-boot for other OSes.

          • So it's only if you buy pretty much any computer you are likely to find in a store then? Wow ... Good thing it is an exception and not the norm!

            • So it's only if you buy pretty much any computer you are likely to find in a store then? Wow ... Good thing it is an exception and not the norm!

              Is there any system that doesn't have a switch to turn SecureBoot off? Even Microsoft's own Surface devices have a switch for it.

        • Because they all need to petition redmond for a signature with the redmond key to be somewhat viable as a competitor to redmond.

          No, you're confused. You're talking about the SecureBoot feature of UEFI, which you can turn off even on Microsoft's own Surface computers. Even then the only motherboards that even have any requirement for the SecureBoot feature at all are ones that want the "Certified for Windows 10" sticker on them.

        • Because they all need to petition redmond for a signature with the redmond key to be somewhat viable as a competitor to redmond. And, of course, it means supporting lots of redmond tech (fatshame32) just so you can boot. BIOS is crappy but so much simpler to deal with, that UEFI is not an improvement.

          This is FUD. The UEFI Forum solicited proposals for companies to provide the root of trust for Secure Boot and all of the big security companies wanted a lot of money to host this. Microsoft offered to host it for free. Any other company could make the same offer the UEFI Forum would gladly accept it and add another root of trust. Not to mention that a requirement to get a system certified for OEM sale of Windows requires that the end user be able to install their own Secure Boot key. This means that a

    • Re:Not a Fan of UEFI (Score:5, Informative)

      by bws111 ( 1216812 ) on Thursday December 20, 2018 @11:29AM (#57836600)

      As is normal on slashdot, 99% of the people complaining about UEFI appear to have absolutely no idea what it is or does. UEFI has nothing to do with 'fancy graphics set-up screens (although it may make creating such screens much easier). On all of the UEFI-based systems I have used, the setup screens look exactly like BIOS screens.

      And WTF does UEFI have to do with giving Microsoft a monopoly? If anything, it does exactly the opposite. The access to firmware functions is provided by standardized UEFI calls, not proprietary drivers provided by a device manufacturer.

      • I have built Tianocore images and booted them in order to understand UEFI so I think it's fair to say I'm in that other 1% and I assure you UEFI is a clusterfuck.

        • I have built Tianocore images and booted them in order to understand UEFI so I think it's fair to say I'm in that other 1% and I assure you UEFI is a clusterfuck.

          That depends entirely on what you are trying to accomplish. TianoCore provides drivers for just about everything. Way more than is needed to boot most systems. THat’s because UEFI is designed to work for everybody in just about every use case imaginable. You could use something like CoreBoot but the feature set is much smaller. Sometimes that is a good thing and sometimes that is a bad thing. It depends entirely on what you’re trying to accomplish.

      • Re: (Score:1)

        by Anonymous Coward

        Some of the people complaining about UEFI may be clueless, but despite that they're not wrong. UEFI is overcomplicated, bloated, design-by-committee, buggy garbage (see also: ACPI).

        OpenFirmware is BIOS done right. But sadly, people don't appreciate Forth so it died.

    • Re: (Score:1)

      by Anonymous Coward

      If you manage desktops for a business, UEFI is both a pain in the but and a God-send.

      A pain in the but because all these new-fangled UEFI machines broke your old imaging process. You've had to adapt to either learn to switch machines over to legacy boot more or (worst case) completely re-design your imaging process from the ground up with UEFI in mind.

      A god-send because it enables some really cool new deployment scenarios, mainly through network booting. So you can set a machine to boot to a network locatio

      • If you manage desktops for a business, UEFI is both a pain in the but and a God-send.

        A pain in the but because all these new-fangled UEFI machines broke your old imaging process. You've had to adapt to either learn to switch machines over to legacy boot more or (worst case) completely re-design your imaging process from the ground up with UEFI in mind.

        A god-send because it enables some really cool new deployment scenarios, mainly through network booting. So you can set a machine to boot to a network location that will automatically deploy the OS. You can even configure the machine to reboot every night and re-image back to pristine, without any 3rd-party software. A god-send because it enables some new security features: namely, validating the boot image, which makes it very difficult for root kits to take hold.

        I remember the Slashdot reaction when MS first announced support for SecureBoot. So many comments about how MS would use it to lock out linux or other open source products. That was nearly 10 years ago, and nothing even close to that has happened, but we have seen a meaningful security benefit.

        You should not be using legacy boot in an enterprise situation. The only exception to that would be if you have some old operating system that does not work except in legacy mode. If you’re booting in legacy mode then your system’s security is about as solid as a slice of swiss cheese.

    • I think that the old BIOS, being a very minimal, compact, low-bug,

      Normally I'd say something like "found the millennial" but you must be Gen-Z as even millennial would laugh at that statement.

      BIOSes have since the early 90s been a clusterfuck of horrendously poorly written workarounds, barely working code messing up half the OSes that required to use them. UEFI is no worse than the old ones, and arguably better since it has provided a means of a non-archaic way of applying bugfixes that didn't involve digging through your junk drawer to look for a floppy drive and hope th

  • 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....

    • I don't think I understand what's intended by "Firmware as a service". What, is the idea that we pay Microsoft a subscription fee to run firmware now?

      • Re: (Score:2)

        by bws111 ( 1216812 )

        Seriously? Firmware as a service has nothing to do with subscriptions or fees. It means that an OS gets access to firmware functions by an architected interface (ie a service) to the UEFI. That is as opposed to BIOS, which provided no such functions, so every device manufacturer had to provide their own interface to their firmware via proprietary drivers.

        • I think my confusion should be understandable. SaaS = You rent software by a subscription. IaaS = You rent infrastructure by a subscription. FaaS = ???

          I'm still not sure what "Firmware as a Service" means from your description. How is Project Mu more of a "service" than existing UEFI?

          • Re: (Score:2)

            by bws111 ( 1216812 )

            I take it as meaning they want to use the 'firmware as a service' aspects of UEFI (all UEFIs), but their current UEFI (TianoCore) is a bloated mess that is too difficult to maintain.

            • I take it as meaning they want to use the 'firmware as a service' aspects of UEFI (all UEFIs), but their current UEFI (TianoCore) is a bloated mess that is too difficult to maintain.

              Microsoft basically wants the ability for the firmware image on the flash part to have multiple signatures. The ME or PSP portion of the flash part would be signed by the silicon vendor. Same with microcode, etc etc. UEFI allows modules. So if a generic module is being deployed then it can be signed by the developer of that module. This would allow security fixes to be pushed down to the flash without worrying about whether the OEM or ODM has decided to roll a new firmware image. This is actually the

        • BIOS always had a standardized set of calls. I don't know where you got the idea that it didn't.

          • Re: (Score:2)

            by bws111 ( 1216812 )

            Haha! Good one! The original BIOS (circa 1981) provided a small set of 'standard' calls for text-mode video, serial port, parallel port, diskette drive, cassette tape, and not much else. By the time DOS 2.0 came out they were already starting to use device drivers, as the BIOS calls were simply not sufficient. When the 386 was released with 'protected mode', BIOS usage dropped to 0, as you could not even access it in protected mode. There are NO modern OS's that use BIOS.

    • 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...

      Actually it never flied at all. Despite how much you revise history, the very first requirements for UEFI mentioned in any Windows certification (specifically when Windows 8 was released) was that for a vendor to get the Microsoft certification for their product they *had* to provide a software switch to disable secure boot, something that Microsoft's own devices do despite them having no incentive or requirement to do so.

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

      You can come and try, but may I suggest you go for my desktop first? You see my device

      • There is no such thing as a UEFI BIOS. Perhaps you are referring to UEFI CSM (Compatibility Support Module.)

    • M$ tried to lock in Windows by making "secure boot" with UEFI... and only they had the cryptographic signing that was accepted.

      SecureBoot is not a Microsoft feature, there's no reason you can't add your own signing keys to it and there's no reason you can't just disable it altogether, even on Microsoft's own Surface computers. Not sure how you manage to be "locked in" by that situation. At the time they even put in a provision to OEMs that if you wanted certification they forced you put in a switch to turn SecureBoot off entirely. That's the exact opposite of being locked in.

  • Solve the forking problem by... forking??? (Score:5, Interesting)

    by nateman1352 ( 971364 ) on Thursday December 20, 2018 @02:28PM (#57837786)

    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 [github.com] 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 [microsoft.com] 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.

    • Your point that MS reinvented the wheel several times for their Surface products is a very important one because they fscked up on the Surface firmware and drivers so many times. Iâ(TM)m on mobile right now otherwise Iâ(TM)d find the links. That said, one example was when MS utterly failed to get the 7th gen Intel core chips to perform as well as other manufacturers because MS wrote some of their own drivers instead of using the ones from Intel. MS said to Fujitsu or some other company, âoeTh

  • 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?

    • Re: (Score:3)

      by bws111 ( 1216812 )

      You do know there are NO OSs that use BIOS, right? Not a single one. It would take one hell of a lot more than 'understand bigger drives' to make BIOS useful, starting with running in other than real mode, and continuing with support of all the device types that have appeared in the last 35 years or so.

      • Re: (Score:3)

        by sjames ( 1099 )

        Yes, I do know that all OSes take over once they are loaded. Another reason why EFI is of questionable benefit.

        Since all EFI and old BIOS seem to be good for is initializing the system, finding, and loading a boot loader, why do we even need to invite the new bugs and new pain from EFI? I've seen plenty of old BIOS that can load from iSCSI, USB, FC, etc.

        EFI seems to suffer very much from second system syndrome as well as kitchen sinkism.

  • I'm putting my money on Toilets as a Service, TaaS.
  • The only appropriate response [youtu.be] to proposing firmware as a service.
  • 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.

Slashdot Top Deals

As you will see, I told them, in no uncertain terms, to see Figure one. -- Dave "First Strike" Pare

Close