01.24.12
Gemini version available ♊︎Microsoft Media Partners Spin the UEFI Abuses
Microsoft’s spin is getting old and rusty
Summary: Another new example of sources that are bribed by Microsoft or allied with Microsoft dismissing the anti-competitive nature of what Microsoft is doing and disseminating insults instead (ad hominem attacks)
THE UEFI tricks that Microsoft uses to harm the competition are not going to make Windows secure. On ARM in particular, Microsoft cannot justify those tricks, e.g. using the “security” excuse. Realising darn well what Microsoft is up to, Katherine writes about the situation, but Microsoft uses its highly biased press partners to whitewash the whole thing. This one come from an author who does not even wish to be identified (which often says a lot) and a publication with Microsoft ties. Microsoft talking points are contained therein and the key development is this:
This argument seemed somewhat settled until Computerworld author Glyn Moody noticed something a little different from Microsoft’s line of argument on page 116 of Microsoft’s “Windows Hardware Certification Requirements” for client and server systems, which bears a publish date of December 2011. On that page, it appears that Microsoft is telling OEMs producing ARM-based machines that secure boot is mandatory, whereas it can be disabled on non-ARM (x86) machines.
The article is designed to discredit those claims and one commenter adds: “In Brazil, the government will be not allowed to buy machines with Secure Boot, since it is against the current legislation by not allowing free concurrence. I see some legal issues in this question…”
It’s not just that. As a Red Hat engineer continues to explain:
The fundamental problem is that UEFI is a lot of code. And I really do mean a lot of code. Ignoring drivers, the x86 Linux kernel is around 30MB of code. A comparable subset of the UEFI tree is around 35MB. UEFI is of a comparable degree of complexity to the Linux kernel. There’s no reason to assume that the people who’ve actually written this code are significantly more or less competent than an average Linux developer, so all else being equal we’d probably expect somewhere around the same number of bugs per line. Of course, not all else is equal.
Even today, basically all hardware is shipping with BIOS by default. The only people to enable UEFI are enthusiasts. Various machines will pop up all kinds of dire warnings if you try to turn it on. UEFI has had very little real world testing. And it really does show. In the few months I’ve been working on UEFI I’ve discovered machines where SetVirtualAddressMap() calls code that has already been (per spec) discarded. I’ve seen cases where it was possible to create variables, but not to delete them. I’ve seen a machine that would irreparably corrupt its firmware when you tried to set a variable. I’ve tripped over code that fails to parse invalid boot variables, bricking the hardware. Many vendors independently fail to report the correct framebuffer stride. And those are just the ones that have ended up on hardware which crosses my desk, which means I haven’t even tested the majority of consumer-grade hardware with UEFI.
UEFI offers no benefits to computer users, especially on ARM-based devices. Microsoft is cheating and then relying on professional liars to cover up with spin. Microsoft never changed. █
“Government attorneys accuse Microsoft of using its monopoly position to bully, bribe and attempt to collude with others in the industry, while illegally expanding and protecting its Windows franchise.”
–The antitrust case: a timeline
ᶃ Gemini Space
This post is also available in 
Content is available under CC-BY-SA