Linux Has Not Won, Microsoft is as Dangerous as Ever, Fie on Secure Boot

Posted by tuxchick on Dec 4, 2012 8:03 PM
LXer Feature; By Carla Schroder

LXer Feature: 04-Dec-2012

I think UEFI Secure Boot is a shuck and a bald-faced Microsoft anti-competitive tool. I'll get to my reasons in a moment, because my most important point comes first:

Every purchase of a Windows license is an attack on Linux. Linux has not won, and Microsoft is as dangerous as ever.

Every time you buy a computer that bundles a Windows license just to save a few bucks over buying a Linux machine, you're shooting yourself in the foot. It doesn't matter that you blow Windows away and install Linux-- it still counts as a Windows sale, which reinforces your vendor's belief that they need Windows users and can safely ignore Linux users. It sends money to Redmond. It rewards all the junkware, adware, and spyware vendors that load their garbage on Windows PCs. And it cements the anti-competitive status quo more firmly. Buying Android devices sends a significant revenue stream into Microsoft's pockets-- Linux PCs and bare hardware are almost our only remaining options to avoid paying the Microsoft tax.

Independent Linux vendors like System76 and ZaReason do more than stuff Linux into off-the-shelf machines. They do their own engineering and design, build with quality components, and use hardware that supports open drivers. So you don't need to worry about custom drivers or lockin, but can use your machines however you see fit. You're not going to be plagued with strange errors and bad performance from sub-par electronics. You get good stuff that you control and better service.

It's obvious that no matter how blatantly Microsoft abuses their market clout there will never be a regulatory remedy. The only meaningful clout is the market, which means two things: buy Linux, and tell vendors how you feel. It takes just a few minutes to tell ASUS or Dell or Costco or Newegg or whoever that they lost a sale because you are a Linux customer. They don't get that message when you quietly purchase products that bundle an unavoidable Windows tax.

UEFI Secure Boot is More Microsoft Abuse

Microsoft has a long history of gaming and bullying standards organizations. Probably the most egregious example was their scorched-earth all-out assault on the ISO/IEC during the MS-OOXML standard debacle, including costing Massachusetts CIO Peter Quinn his job, and flooding ISO with new members whose sole purpose was to vote for MS-OOXML.

Microsoft scored a quiet coup when they got their proprietary, closed exFAT filesystem (essentially it's FAT64, an extension of the creaky antique FAT12, FAT16, and FAT32 filesystem line) made part of the SDXC specification for Flash storage media. The Free exFAT driver is immature and its developers are working in the dark because the spec is closed. Nor is there a commercial exFAT for Linux users, but only the Tuxera driver for OEMs.

Those are just two out of many hundreds of possible examples. And now we come to the UEFI Secure Boot. A lot of people are all excited over the phrase "Secure Boot" because it sounds like a good thing. Sure, who wouldn't want a secure boot to keep all those pre-boot malwares off their nice Linux boxes?

What Linux pre-boot malwares? If you're multi-booting Linux and Windows, then you're at risk for everything. If you're not running Windows I can't promise that you're immune. But your risk is magnitudes lower.

This is wrong...see Correction, below

The biggest flaw in Secure Boot is the spec requires a single Platform Key. You can add more keys, but they must be signed by the Platform Key. This is the cause of all the woe from Microsoft requiring all Windows 8 systems to ship with Secure Boot turned on-- if you want to multi-boot Linux and Windows 8 you have to disable Secure Boot, or figure out how to generate keys for Linux that are signed by the Windows Platform Key. You cannot easily use Secure Boot for Windows 8 and disable it for Linux.


A reader kindly pointed out how the Platform Key works, which is not how I described it. This is a fundamentally important point, so please read this correction:

Quoting:The platform key is the firmware vendor's key. Each motherboard will have a platform key controlled by the firmware provider. That key is used to sign the actual SB keys packaged with the system at ship time. Microsoft has no involvement in that at all, except to ask the vendors to sign their key. If the mobo vendor wants to include Microsoft's key, they put it in the list and sign it with the platform key. If they want to include anyone else's key - as well as or instead of Microsoft's key - they put it in the list and sign it with the platform key. The concept that the single platform key controlled by the firmware vendor is used to sign *multiple* OS vendor keys is expressly designed to allow multiple keys to be trusted 'from the factory', precisely the opposite of what you suggest in the article.

This is the only plausible way to design it: it's just the root of the trust chain. There has to be one in any chain of trust. The only possible choices for who should own the trust root are a) the vendor of the firmware and b) the user, and Secure Boot expressly allows for both.

Diverting Linux Resources

Much too much of Linux history is about workarounds and diversions. Here we are with yet another one forced on us by our good friends in Redmond. Red Hat, SUSE, Canonical, and others have devoted a good chunk of money and developer time to trying to resolve Secure Boot follies. This is yet one more Microsoft tax that all of us pay, even when we don't buy Microsoft products.


[sf-lug] anti-ooxml petition picking up steam "It is stunning to see that Microsoft has succeeded in actually bottling up the ISO by flooding ISO with members who will only vote on one issue: MOOX. They fail to show up for any other vote, and so nothing gets done."

Linux Foundation Releases Statement Calling for National Bodies to Vote "No" on OOXML "I believe that Microsoft has profoundly damaged the credibility of the standard setting system."

Rod Smith's Managing EFI Boot Loaders for Linux: Dealing with Secure Boot is the best Secure Boot howto I've found. Be sure to pass a dollar or two into his PayPal account if you find it useful.

Microsoft has never stopped trying to control the bootloader-- He Who Controls the Bootloader describes how MS sabotaged BeOS. Launching the BeOS on Hitachi FLORA Prius systems is the cached howto enable hidden BeOS installations that is mentioned in the article.

Return to the LXer Features

Subject Topic Starter Replies Views Last Post
UEFI ruse wanderson 34 4,524 Mar 8, 2013 4:01 PM
Not joining the either/or position Steerpike 21 4,301 Mar 7, 2013 9:59 AM
only microsoft? questioner 1 3,309 Dec 7, 2012 6:12 PM
Someone had to say it djohnston 40 4,323 Dec 7, 2012 4:58 PM

You cannot post until you login.


  Latest Features
Scott Ruecker: My Linux Laptop
May 08, 2022

Scott Ruecker: Laptop Dual Boot Project: Part 2
Nov 30, 2021

Scott Ruecker: Laptop Dual Boot Project
Nov 30, 2020

Scott Ruecker: Lenovo Laptop Love..Not!
Nov 01, 2019

James Dixon: Attempting to install Linux on a new laptop, a follow-up
Sep 21, 2019

James Dixon: Attempting to install Linux on a new laptop
Jun 07, 2019

Hans Kwint: Updating from Ubuntu LTS 16.04 to 18.04
May 03, 2018

Dr Tony Young: A KMail Breakthrough.
May 01, 2016

James Dixon: Installing jstock with Slackware 14.1
Jan 19, 2016

James Dixon: Installing sbopkg with Slackware 14.1
Jan 16, 2016

View all

  Search Features

Search LXer Features:

[ Copyright © LXer | All times are recorded in Central Daylight Time (CDT) ]

[ Contact Us | Privacy Policy | Terms of Service | About us | rss | Mobile ]