In my mind, firmware is the low-level software that's embedded in a device, and is both hard to change and unlikely to need to change, because it provides utility foundational to using your hardware. How do you turn that into a service?
Edit: apparently I can't read because it was right in there: "Firmware as a Service optimizes UEFI and other system firmware for timely quality patches that keep firmware up to date and enables efficient development of post-launch features." So basically, take the limitations I mentioned and get rid of them.
"As a service" in this context means the mental model / delivery pipeline is more like subscribing to a service than purchasing individual software. I'm sure this makes more sense to Microsoft folks; open-source folks are more likely to call it "continuous deployment" or "living at HEAD" or something. They compare it to Windows-as-a-service, the idea that you run the current version of Windows, not the version you paid for and future updates involve change control and procurement and other bureaucracy.
Firmware does change and often has security vulnerabilities, so you do need to be keeping it up to date the way you keep your OS up to date. Among other things, it includes processor microcode / errata fixes like some of the Spectre, Meltdown, etc. mitigations. It would be nice if we lived in a world where this doesn't need to change, but it does, and thankfully it is firmware and not hardware.
Hardware met Software on the road to Changtse. Software said: “You are yin and I am yang. If we travel together we will become famous and earn vast amounts of money.” And so they set forth together, thinking to conquer the world.
Presently they met Firmware, who was dressed in tattered rags and hobbled along propped on a thorny stick. Firmware said to them: “The Tao lies beyond yin and yang. It is silent and still as a pool of water.
It does not seek fame, therefore nobody knows its presence. It does not seek fortune, for it is complete within itself. It exists beyond space and time.”
Hardware and Software, ashamed, returned to their homes.
Per Wikipedia, it was coined in 1967 to refer to the glue code that existed at the boundary of hardware and software.
Or, in other words, any code which hooks directly to the hardware on one side and exposes abstractions (like an instruction set) that software can code against on the other.
I always assumed "firm" stuck, as in "You'll have a helluva time changing it, because it's the code that has to deal with all the complex electrical engineering stuff."
(E.g. processor errata, patched board mistakes via fuse or EEPROM, side effects of power supply undervolting or clock skew, or pre-initialized system murkiness)
It's integrated into recent distros, seamlessly shipping firmwares for supported vendors (Dell came first, HP arrived soon after, and I think I read Lenovo was being worked on) like this MS project does, or Apple has been doing for years.
They do, but Windows updates are much more opaque (IME). Seeing microcode being updated brought home how small the distance between hardware/firmware and software, which was OP's point.
Correct. If they push a little more it will just become part of the OS. Firmware should consist of minimal hardware init and a boot loader and nothing more.
BIOS firmware has been flashable from the OS since, what, the Windows 98 days? I'm sure I remember updating the BIOS on an old Pentium III ThinkPad in this manner.
> In my mind, firmware is the low-level software that's embedded in a device, and is both hard to change and unlikely to need to change
That may be a model suitable for a single machine. Once you get to hundreds, you get intimately familiar with how to update everything and how common firmware bugs are.
This sounds like a good thing overall, considering most OEMs can't even be bothered to update devices for Spectre that are older than 2 years.
However, I can't help but think that this is yet another thing on NSA/FBI's wishlist to Microsoft, just as most of the tracking stuff in Windows 10 seems to be. Say hello to "targeted malicious updates" by the U.S. government.
Yes, I know this was probably possible with the Windows updates already, but I imagine the malicious firmware will be much less likely to detect = the agencies can use this against many more people.
>"Firmware as a Service optimizes UEFI and other system firmware for timely quality patches that keep firmware up to date and enables efficient development of post-launch features."
sounds like an excuse to deliver unfinished software. remember that Microsoft got rid of its Windows testers and moved the burden of testing on the users.
Not to be too anti-microsoft. But this seems like they're bringing the EUFI into windows, therefor allowing them in the future to make it harder than it already is(or eventually impossible) to actually get into the EUFI to install a competing OS.
I admit I'm decently "tin-foil hat" about microsoft, but every new laptop I've bought over the last 10 years have been progressively harder to get into UEFI/BIOS to remove windows and install a new OS.
As a guy who (used to) dual boot, I think I can offer some insight.
When I had Windows 10 dual booted with Linux, Windows had this extremely annoying habit of changing my UEFI boot order when it updated so that Windows was the first to boot, rather than Linux (where I can use GRUB to load Windows). I then had to manually revert the change at the bootloader.
With this exposed, it would not surprise me if their "default" implementation is to make sure Windows boots first, and revert the UEFI boot up that upon every boot up. An average user will likely not be aware of that, or the heavy Linux user who only boots into Windows occasionally.
sure, bitlocker is a major pain on my dual boot device.
But isn't that IMPROVED by open sourcing the implementation? It exposes that kind of stupid behavior, and for the implementation to be useful, that stuff can't be in there anyway. Maybe I'm completely misunderstanding what's being open sourced?
I'm not certain what is open sourced. What I saw is that Windows iis going to be able to access certain features of uefi, so they would be more standardized than anything.
Also, I didn't even have bitlocker turned on, that was just Windows being a PITA with regards to daul booting
I am one of those wary of Microsoft. The current CEO was around during the Halloween Diaries. Even if he is well meaning, he is just an employee who can be replaced any day at the whim of large shareholders like Ballmer and Gates who consider Linux to be a virus.
Ballmer is still Microsoft's single largest shareholder, and he has seen his personal wealth grow dramatically under Nadella’s tenure. You’re telling me he hates Linux so much that he’s willing to tank his own fortune, to the tune of billions of dollars, to stab ineffectually at it? Please.
Nobody at Microsoft ever had a committed ideological opposition to Linux, it was a pragmatic decision based on what they perceived as a threat to their business. That certainly doesn’t negate the damage of all the shit they pulled, but it does mean that it is highly unlikely that they’re going to reverse course and start extinguishing Linux for ideological reasons now that they’ve figured out how to make money without Linux being the enemy.
The problem is what they will do when they are at the top (or hitting rock bottom). Or when their stakeholders want to milk the cow.
It's similar to how you don't want companies to have your personal data, even if you trust them "100%". When money becomes a problem, or a solution, you'll be their last priority.
Some of the news about Windows 10 would be unthinkable a few years ago. Priorities change, and this company in particular has a history of being extremely hostile.
You’re making a different argument here then the person I replied to though. solarengineer was implying that WSL is a plot to extinguish Linux, which is ridiculous.
But that’s not saying that Microsoft is 100% trustworthy or that they will never do anything bad ever again. I’m only saying that the “sinister plan” for this one particular software component is to make Windows more useful to Unix-land developers, to try and get them to buy Windows PCs instead of the usual MacBook Pro. Notice how that explanation still assumes Microsoft is still doing it for their own financial benefit, but doesn’t require an agenda to destroy Linux. They have realized that this isn’t a zero-sum game.
I am convinced this is a “plot” to kill the linux desktop / keep people on windows. Its better, free and you control it - why would they not want to kill it.
Because almost nobody uses it so they don't care. The only reason they even made WSL was to compete with Mac, and make devices with odd hardware that didn't easily run desktop Linux (like Surface) more appealing to developers.
Linux will run on almost everything these days. Of course they care: Linux desktops are finally starting to run out of the box. Kill the baby before it grows up.
It's disappointing that literally anything that Microsoft does has this same comment right on top. Does it add anything to the discussion? We've all seen this comment at least a thousand times in the last 15 years. You haven't even taken the trouble to chalk out a plausible path for embracing and extending. Forget that, you haven't mentioned who they're embracing and extinguishing. At this point it's just repeating a tired meme for the sake of karma.
Not calling you out in particular, but here are other tired HN memes that can be reliably milked for karma
* If you're not paying, you're not the consumer, you're the product.
* It can be difficult to explain to something to someone when their job depends on not understanding it
The various responses to my "embrace, extend, extinguish" got me thinking about why I continue to be apprehensive about Microsoft. Perhaps it is because of my experiences with Microsoft and their dirty ways. They have a history of screwing the user over.
A bit of a rant/recall follows:
I had lost content to a doublespace bug and was asked to pay for drive space via an MS DOS upgrade to 6.22, I have seen how Microsoft encouraged piracy in schools and colleges in India, how they have used FUD to suppress open source education and adoption efforts in the government and education spaces. I also recollect all the dirty stuff around Frontpage "extensions", IE extensions + IE's excessively forgiving tendencies to HTML violations and incorrectness, how MS took spyglass software and did bad things with it. Later, the Haloween Documents showed how MS said one thing in public and plotted another thing in private. They were Gurus of scheming behaviour. Then there was the Microsoft Windows tax, where you had to pay the Windows license fee even if you planned to run Linux on your computer. I also had to struggle with the MS Java, J++ rubbish. Microsoft used to do such bad things so deliberately. I also recall bad things around UEFI, around making it difficult for Linux distros to dual boot on laptops (which got resolved later).
Recollecting all of the above doesn't make it easy for me just to accept that with some code releases and PR announcements, MS would have turned over a new leaf.
People behave as they are measured. Satya Nadella is changing the public image of Microsoft, and even walking the talk. I learned just now on Wikipedia that he tripled MS stock, and that anonymous polls within MS have called him the best CEO of a US company. I am not an MS employee, so I won't know if he has managed to change the internal cultural tendency of being insincere and vicious (see above for examples).
I'm just apprehensive that at the end of the day, he is just an employee. Employees can get fired anytime, overruled anytime.
Perhaps I am being unfair to MS and Satya Nadella, and to all those MS employees who are giving their best. To them all - I apologise for my ill will.
Don't forget the covert funding of the SCO trial, the press coverage of which absolutely did its job in frustrating my efforts to get Linux more widely adopted in my Fortune 250.
I don't apologize for my "ill will" and suspicion. You lie down with dogs; you wake up with fleas. I get it: in some cases, you play the hand you're dealt. But don't expect me to make or infer some distinction about which side you're on.
I think a lot of the apologists for Microsoft here on HN just didn't grow up with the Microsoft of the 90's, and didn't see them buy, steal, or destroy every interesting technology to come along in the late 90's and 2000's. (Shall I go through THAT list?) I suppose they can be forgiven for having rose-tinted lenses that only see back about 5 years. To them I say, just let us have our bitterness. It's been earned.
You can use some other words instead, for example "abbandon". Or they leave the product/feature so buggy that its useless. If you rely in MS tech, you always run the risk that it will be discontinued, or became unusable. I don't suppose this is done out of malice, MS is a corporation, it operates organically. I can imagine one manager fighting for his feature to get into the Windows OS, because then he can get a bigger bonus. Even if the feature is not complete, even if the users wouldn't want it, he can use internal politics to get the feature in, so he can get his bonus.
Microsoft no longer sees Linux as a threat because it isn't a threat to their business anymore. Any damage that Linux can do has already been done and can't be changed. So few people use Linux on the desktop that they have no reason to even be worried in trying to prevent people from using it. All that would do is push developers back towards Mac, which is the opposite of what they're trying to accomplish.
Microsoft has seen huge growth under Nadella, and that was accomplished through selling cloud services. Linux does not threaten this business model or the future of the company in any way. There's nothing to "Embrace, extend, extinguish".
Absurd comment. Why have another operating system attached to my operating system? Aside from obvious reasons why this is a bad idea (performance, bloat, security, ads...) this sounds like an operational headache and any person doing this everyday would be reducing their productivity. If you wanna use Windows just use Windows. If you wanna use linux, just use that.
In the "Introducing Project Mu" blog post it says "The Microsoft Devices Team is excited to announce Project Mu, the open-source release of the Unified Extensible Firmware Interface (UEFI) core leveraged by Microsoft products including both Surface and the latest releases of Hyper-V."
And I saw in one of the tickets for Virtualbox [1] that:
You go VM-entry, execute guest, VM-exit. Cooperatively. Unfortunately MS launches Hyper-V at boot time as a service and keeps a hold of the VT-x, regardless of use or not
and
This is a problem with Hyper-V being too aggressive and not releasing VT-x once it's got a hold of it. VMWare and VirtualBox for example can not only coexist, but they can run concurrently. Not so with Hyper-V.
So does that mean that we can finally have virtualbox/vmware when hyper-v is enabled but not in use, or do they have to open up more in order to get this fixed?
I am afraid that may be the case as the only thing I saw in my first quick glance was VTd(directed io) code[2] and in a quick glance in other repositories I saw VMCALL but I haven't found VMXON yet, so maybe it is a step in the right direction.
No, Mu has nothing to do with this, Mu is a fork of EDK2 with a nice GUI and continuous update whatever stuff. This is firmware. Hyper-V uses firmware to boot an OS, but that's all inside the VM.
More to the point though, MS recently made a public Hyper-V API thingy. Windows Hypervisor Platform I think it's called. It's similar to how KVM, bhyve (vmm.ko) and Apple's Hypervisor.framework (its kernel counterpart actually) work. Now you can use Hyper-V itself + any third party frontends that use that API. E.g. the Android emulator is going to switch to this.
VirtualBox/VMWare should leverage these APIs but they don't because they're way too invested in their custom kernel modules already.
Issue is you'll likely still need a bunch of binary blobs to boot or use peripherals. And you've still got the Intel ME running. But as far as Microsoft goes, it's definitely evidence that FOSS is here to stay.
Actually it doesn't look that way. You can run Linux on a surface device just fine. The tricky part is largely what they just released: interacting with UEFI and ACPI peculiarities like "connected standby."
Though the surface laptop does have an Nvidia GPU, so there's that piece of proprietary bullshit. :)
> You can run Linux on a surface device just fine.
Where "working" includes problems like multitouch not working, pen not working, some problems with wifi and cameras not working. Some of that can be made to work by using a custom kernel, but the compatibility is decidedly worse than comparable devices.
i just don't understand how his take is at all relevant in modern times. i am sure he uses microwaves, refrigerators, homes, vehicles, etc. on a daily if not hourly basis that have non-free software and firmware. what does he or anyone even do with open source, free firmware?
> As for microwave ovens and other appliances, if updating software is not a normal part of use of the device, then it is not a computer. In that case, I think the user need not take cognizance of whether the device contains a processor and software, or is built some other way. However, if it has an "update firmware" button, that means installing different software is a normal part of use, so it is a computer.
That... Doesn't make sense. What if the "button" (probably a jumper or connector on the motherboard) isn't normally accessible to the end user, like a lot of embedded devices? If it has a CPU, ROM, RAM and runs code it's a computer!
I think the extreme stance still makes sense, as some things still meet all the criteria. You can get an old ThinkPad or an Asus C201 Chromebook and run libreboot on it with a GNU/Linux distro using no blobs. These aren't bleeding edge, they're not perfect, and they don't come totally free out of the box, but they show that this level of freedom is possible. I think that's enough for us to want to strive for it.
I don't understand this comment chain, replies, patterns of downvotes at all.
Nothing, anywhere, indicates that Project Mu has anything to do with "other OSes" on Surface devices. And the grandparent comment is a direct implication that Project Mu would/will be critical to Linux on Surface.
This isn't to say that this is not neat, from what I've heard about TianoCore and the codebase, but linking this to Linux on Surface seems completely invented and just a weird comment given that it already works pretty well, minus missing drivers that will still be missing even with an OSS UEFI core.
Riiight... as the author of the Mu editor (a volunteer led code editor aimed at beginner Python programmers and educators -- https://codewith.mu/), this was rather a surprising turn up for the books this morning.
I guess "just Google for Mu" won't work any more. Beginner coders are just gonna love "Firmware as a service". ;-)
> I guess "just Google for Mu" won't work any more.
And it never did work for such an ambiguous term (greek letter? Micron Technology stocks? Manchester United?), unless you googled "mu editor" in which case you're still fine.
Has it so far? Did you say "Mu"? In that case people could have googled for all kinds of things: Mew or moo or me or something else. And even if they knew how it is spelled the first results would have been the greek letter mu, the zen mu, or the football team Manchester United. In Sweden a lot of the results were about a children's tv-programme, Mamma Mu.
Your editor is not on the first, second or third page of Google, I didn't look any further, because who does?
It's probably good for you that you realised saying "just Google for Mu" won't work "anymore".
I guarantee "Python Mu" will continue to bring up codewith.mu and "Mu" will continue to bring a million random sites as it is an extremely common letter and abbreviation. If Googling "Mu" was bringing up codewith.mu for you it was because Google already knew your context already from history with the project or Python searches.
Sidenote: If you want a unique name don't pick one that is 2 letters (or 1 technically).
Microsoft could have contributed to coreboot instead if they claim to be so opensource-friendly. Or wrote firmware in safer language like Rust. Tradional UEFI code is a total mess, from programming practices view and from security/safety point of view too. For a long time they stuck with Python 2 only for their tooling, C89 compatibility, non-standard types, etc.
P.S. Note, that most of the UEFI is not open source - so called PI code (Platform Initialization), which performs real platform booting is closed source in almost any board. Coreboot is targeting this stage too.
PI code on x86 is provided by Intel. You can't ever open source it.
Coreboot, like other offerings, sets up the basic stack and jumps to Intel provided blob, which then jumps to the provided hook in Coreboot when a particular part of initialization is done. DDR controller, microcode patching are all done at start-up via this mechanism.
Intel claim one reason that you just have to trust their binary blob PI/FSP to do these kinds of things is because at each stepping release of a given CPU there are different early boot errata and microcode abilities until microcode is loaded from flash. It's a bit of a stretch, but the insulation can be thought of as useful in the right light.
This project and coreboot seem to me, complimentary. It is already possible to run TianoCore over coreboot, it seems it should be possible to run Mu with it as well given some work.
Disclaimer: I do work for MSFT but never on UEFI - this is an outside observation
If Project Mu requires UEFI, then you'd need coreboot+TianoCore+Mu. In theory contributing to coreboot would have been far more useful, but their idea of being able to easily update firmware would work better on UEFI. Coreboot does allow easy flashing by default but it's not really meant to be enabled on user systems (since it allows for "firmkits").
Suppose I want to get into hacking UEFI firmware. Does this mean I can buy some Microsoft device, download the C++ code for the firmware, make some changes if I want to, compile it, and load it onto the device?
If you're flashing via the UEFI interface itself (which can have a very fancy terminal), the firmware might need to be signed. I bet Microsoft will not share the signing keys.
That is only used to check firmware signatures, not UEFI binary signatures. You should be able to add keys to DB and KEK at your leisure. Also Microsoft has a paid program to sign UEFI binaries (that's why you can boot most Linux distributions on secure boot hardware).
You may be able to build this, put your existing device into unsigned mode, then chain from the UEFI shell [1] into this - or just put it on a FAT32 flash drive as \EFI\boot\bootx64.efi.
On the "embedded" side, I'm pretty sure u-boot can load EFI binaries now.
Project Mu[1] is already a taken name. It's not in the same field, so not a trademark violation, but for those of us who fall into both categories I will never mentally think of this product when I hear Project Mu, because there's so much history behind the original.
Great. So we have now another meaning for FaaS (Functions as a Service vs. Firmware as a Service). I was slightly confused while reading that article until I noticed that they're talking about Firmware as a Service (whatever that even means).
Unfortunate name collision with the excellent mu editor for python. I wish people would Google the name of the product they're launching before launching it.
Hardware is about 10 years behind the rest of the software world and hasn't discovered the benefit of open source yet. I have talked to some firmware devs and the idea of open source is totally alien to them.
This is not providing anything that wasn't possible before. You could both create your own uefi software and potentially load custom firmware if the device didn't lock it down with signature checks.
Mu is one of the few Python code editors that is actually great when teaching kids "normal" (i.e. non-visual) programming: https://codewith.mu/. It has several modes that make it easy to e.g. start developing for the micro:bit or create PyGame games. It's not nice if a big company takes over a name already used by an open project - whether by ignorance or negligence.
I mean, you've been able to brick hardware on Linux before in earlier versions of the kernel, where the firmware would get mounted, causing the user to blow away parts of their firmware when they wiped their drive (figuring it was just a recovery partition).
They've always had firmware updates for PCs and I'd rather have an industry wide open source solution that individual OEMs. Just recently Lenovo messed up flashing a TB chip firmware and bricked several high end notebooks.
Apple did firmware updates as part of their OS updates [edit: on Mac], and they did fairly well although I seem to remember one update that did something nasty to one set of machines.
> Copyright (c) 2012 - 2017, Intel Corporation. All rights reserved.
> Copyright (c) 2017, AMD Incorporated. All rights reserved.
> THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE
From the boot options screenshot, I can't find any trace of the one thing I look for in UEFI implementations - ability to easily unlock the secure boot state and boot some arbitrary OS. This seemingly fails to meet even the lowest bar for a good-enough UEFI implementation.
In my mind, firmware is the low-level software that's embedded in a device, and is both hard to change and unlikely to need to change, because it provides utility foundational to using your hardware. How do you turn that into a service?
Edit: apparently I can't read because it was right in there: "Firmware as a Service optimizes UEFI and other system firmware for timely quality patches that keep firmware up to date and enables efficient development of post-launch features." So basically, take the limitations I mentioned and get rid of them.