Linus describes Secure Boot as being “pushed in your face by people with an agenda.” But his real problem is that Secure Boot would then imply Kernel Lockdown mode.
Source: Torvalds Expresses Concerns Over Current “Kernel Lockdown” Approach – Phoronix
At its WinHEC hardware conference in Shenzhen, China, Microsoft talked about the hardware requirements for Windows 10. The precise final specs are not available yet, so all this is somewhat subject to change, but right now, Microsoft says that the switch to allow Secure Boot to be turned off is now optional. Hardware can be Designed for Windows 10 and can offer no way to opt out of the Secure Boot lock down.
via Windows 10 to make the Secure Boot alt-OS lock out a reality | Ars Technica.
This is pretty obviously a firmware bug. Writing UEFI variables is expressly permitted by the specification, and there should never be a situation in which an OS can fill the variable store in such a way that the firmware refuses to boot the system. We’ve seen similar bugs in Intel’s reference code in the past, but they were all fixed early last year. For now the safest thing to do is not to use UEFI on any Samsung laptops. Unfortunately, if you’re using Windows, that’ll require you to reinstall it from scratch.
At the implementation layer, we intend to use the shim loader originally developed by Fedora – it’s a smart solution which avoids several nasty legal issues, and simplifies the certification/signing step considerably. This shim loader’s job is to load grub2 and verify it; this version of grub2 in turn will load kernels signed by a SUSE key only. We are currently considering to provide this functionality with SLE11 SP3 on fresh installations with UEFI Secure Boot present.
Responding to a query from iTWire about what OpenBSD, widely recognised as the most security-conscious UNIX, would be doing to cope with “secure” boot, De Raadt said: “We have no plans. I don’t know what we’ll do. We’ll watch the disaster and hope that someone with enough power sees sense.”
via OpenBSD’s de Raadt slams Red Hat, Canonical over ‘secure’ boot.
Red Hat’s method of ensuring that PCs certified for Windows 8 can boot GNU/Linux, announced by its community distribution Fedora, is to sign up to the Microsoft developer program and obtain a key which will be used to sign a “shim” bootloader.
With the GPLv3-licensed GRUB2 not being an option, Canonical then explored using the GRUB Legacy release with EFI patches on top, but they didn’t want to touch that aging code-base. Canonical has decided to use Intel’s efilinux loader that is more liberally licensed and they’re able to make some modifications to provide a simple menu interface.
via [Phoronix] Ubuntu’s Plans To Implement UEFI SecureBoot: No GRUB2.
The resulting mechanism planned for getting the keys automatically distributed is to utilize Microsoft key signing and registry services. This obviates the need for every customer to have to round up a collection of keys for multiple operating systems and device drivers. Microsoft will provide keys for Windows and Red Hat will provide keys for Red Hat Enterprise Linux and Fedora. Similarly other distributions can participate at a nominal cost of $99 USD – allowing them to register their own keys for distribution to system firmware vendors.
Summary: The drumbeat from Linux advocates about a key security feature in Microsoft’s forthcoming Windows 8 is getting louder. They call it an anti-Linux plot. But the two leading PC makers disagree with them. I’ve got exclusive details.
via Leading PC makers confirm: no Windows 8 plot to lock out Linux | ZDNet.