02.19.13
ZaReason Criticises Microsoft’s UEFI Restricted Boot Practices
Summary: ZaReason joins opposition to restricted boot, whereas others reluctantly adopt it
THE UEFI saga does not simply end… and that’s a good thing!
According to some extraction work by Pogson, there is OEM pushback against what Microsoft was scheming:
She starts by pointing out that “SecureBoot” is a brilliant scheme by M$ to extend its control of hardware-suppliers. Eventually, the supply of machines that shipped “7″ without UEFI/Secureboot enabled will dry up and */Linux will have to deal with it. End-users tend not to want to disable a “security” feature. That it’s mostly a “security” feature for M$, not users.
A few days ago I recommended ZaReason to a person who was looking for a GNU/Linux (preinstalled) box. They seem like a decent business which antagonises restricted boot as everyone should.
As one person told me today:
Accommodating Restricted Boot is a fruitless task that only serves Microsoft Microsoft pretends to leave an escape route open only to lure more people into their trap which they can spring at any time for any reason. We must reject UEFI and restricted boot.
New coverage from London says that Fedora takes a step to eliminate restricted boot:
When users disable the security checks in the Shim Secure Boot bootloader, the latest Fedora 18 kernels will disable any restrictions that are caused by their Secure Boot support. This means that Fedora now offers a very simple way of neutralising any Secure Boot restrictions that can be used uniformly on all systems and doesn’t require users to disable Secure Boot in the UEFI firmware setup.
Here is another update from London:
The Sabayon developers have released version 11 of the Gentoo-based Linux distribution. The 64-bit live images of Sabayon 11 can now boot and install on UEFI systems with Secure Boot enabled, as the Sabayon developers decided to adopt Matthew Garret’s signed-shim. A SecureBoot key is in the /SecureBoot directory of the live media and can be used on initial booting, while a SecureBoot keypair is generated during installation and can then be added to the firmware’s database, which allows users to sign their own binaries.
This is not a great solution because it leaves many distros out in the cold. Companies like Red Hat and Canonical, joined by fronts like the Linux Foundation, should have filed antitrust complaints. They didn’t. █
