> I think understandably, everyone is concerned because it felt like an affront by MS against Linux. But, I don't think that was their thought process at all.
Given Microsoft's history, it's hard to really be sure. It's been a quarter century since The Halloween Documents and Microsoft definitely gives the air of contributing to the open source ecosystem today, but giants like having a big moat to defend, and old habits die hard. And Microsoft definitely has a reputation, even if, technically, undeserved.
There was nothing to be gained in this except ill will. Hanlon's Razor suggests they were in a hurry to fix a security issue and didn't dot their i's on checking for dual boot systems.
It's a trolley problem, and it's not in Microsoft's locus of control to keep dual boot systems dual booting. So they don't try.
They have never, ever supported anything other than the Microsoft bootloader[s], and if you work around that for instance it's pretty trivial to blow up your data by hibernating Windows and booting into a different partition. Resuming hibernation loads the old MFT onto the modified partition and you pretty much lose everything.
>hibernating Windows and booting into a different partition.
Definitely to be avoided, along with a few other considerations.
But experienced multibooters can usually reboot so quick that they have not had any need for hibernation since forever. It's almost like a valid excuse to not fully reboot a sluggish machine, more so than an energy-saving success. But I don't blame them.
Keep in mind that the default since the beginning of Linux is for someone who wants their PC to be completely Linux, never had a need for anything originating from Microsoft whatsoever. Something in firmware would really be the worst and it was immediately obvious when UEFI & GPT were foisted, with Microsoft SecureBoot to boot, that something was rotten somewhere.
A bigger threat than Linux was actually Windows 7, but with this exact hindsight now it can be seen how the knife was much further twisted for Linux well beyond the effective lifetime of W7. This was not just collateral damage, and it keeps on giving as if booby-trapped or time-bombed.
Also remember that until Windows Vista, motherboards and business machines from all major manufacturers were always common where there was no way to alter the BIOS itself in any way without physical access. Like a jumper on the board internal to the PC. Sometimes special key combinations on laptops accepted only from its built-in keyboard.
With BIOS settings only accessible to non-local users occasionally on specialized enterprise models according to options if present.
When you wanted to upgrade your BIOS, or "re-flash" it due to something like power line corruption, you always booted to the floppy containing the desired firmware after enabling the delicate flashing operation manually. By the time Vista arrived it was often a bootable CDROM, or a USB stick formatted FAT32 with DOS to substitute for a floppy. Whichever way you did it you wrote the same binary file into the BIOS chip, then with further access completely disabled after that, never need to worry about malicious firmware whatsoever as long as you used a clean binary.
The only possible way for a rootkit to infect your machine was to reside on your HDD. Usually in some of the spaces outside your filesystem that were so commonly unused it could lurk there and persist in spite of re-formatting.
But no rootkit or preboot contamination could withstand a complete HDD zeroing, or replacement HDD if needed under emergency conditions.
Well one day Microsoft must not have wanted people to ever boot DOS again, so they developed a need to access every BIOS from within Windows NT6, and manufacturers conformed. It only bricked machines significantly for a few years while the DOS way continued to be flawless for a while there.
It's a slippery slope, this got much worse once they forced UEFI on consumers, and malware can now reside in the preboot environment itself, which can often also access the web if connected.
Plus the motherboards have much more space for this kind of thing.
With Windows Servers and general Macs well-established beforehand at using EFI to restrict booting to only the exact OS that it was shipped with.
And everything on that Microsoft webpage introducing the advent of UEFI & GPT as a complete advantage in many ways, looking suspicious and turning out to be completely false without even waiting for the 20/20 hindsight there is now. The whole thing!
The cloak has now been further removed from this "false sense of security" system but surely not everybody wants to say out loud how sparsely-clad the emperor has become as he struts as if to demand the full respect once deserved.
So there hasn't been a physical way or available setting to prevent malicious access to sensitive PC firmware for quite some time, and who's most likely to blame for it?
No Windows "update" has ever made sense to change anybody's BIOS or UEFI firmware without being absolutely stupid as shinola, not like there was any question before this either.
This is also beyond most user recovery if you get malware in your UEFI.
Zeroing a HDD or SSD won't help you now like it would with BIOS.
Given Microsoft's history, it's hard to really be sure. It's been a quarter century since The Halloween Documents and Microsoft definitely gives the air of contributing to the open source ecosystem today, but giants like having a big moat to defend, and old habits die hard. And Microsoft definitely has a reputation, even if, technically, undeserved.