Getting at best and downright impossible in some cases. Still, slowly, ever so slowly, progress is being made.
First, the bad news. Trouble with a kernel driver in some Samsung laptops equipped with UEFI have caused them to "brick" simply by trying to boot Linux on them. This, however, is not a problem with Secure Boot. Instead, it's a problem with how Samsung has implemented UEFI.
UEFI Secure Boot Linux expert Matthew Garrett explained, "The samsung-laptop driver is a slightly weird thing. By 2010 (when it first appeared) most vendors had moved over to using some level of firmware abstraction, either using ACPI [Advanced Configuration and Power Interface] or WMI [Windows Management Instrumentation]. Samsung still seemed to be stuck around a decade earlier - they were providing a region of memory at a known address, and you'd read that address to find a bunch of offsets. Then you'd write magic values based on those offsets to magic system IO ports based on those offsets and something would happen."
That "something", he continued, was that these "writes were triggering System Management Mode [SMM], a special x86 CPU mode where the processor executes code from memory that the OS can't see, without telling the OS that it's doing so. There's nothing especially new in this (SMM first appeared in the 386sl back in 1990), but it also means that you depend on the system vendor not changing the interface without telling you. Turns out that Samsung apparently changed their platform interface when they moved to UEFI, but didn't actually do anything to prevent old drivers from breaking things - performing exactly the same series of accesses on some modern Samsung laptops gives an uncorrectable machine check exception (in the best case) or destroys your firmware (in the worst case)."
There may also be other problems with UEFI-equipped Samsung laptops and Linux. The H reports that "Samsung developers have been attempting to develop a firmware update to prevent the problem for several weeks."
In the meantime, Linus Torvalds has merged two changes into Linux, which will prevent the Samsung-laptop kernel driver from being activated when Linux is booted with UEFI. This means that within the next few days, as the change progresses from the kernel to the various Linux distributions, you'll be able to boot Linux on these systems without bricking them.
Some other systems are still having trouble. In particular, some UEFI Secure Boot-equipped Toshiba laptops won't boot Linux at all. According to Garrett, "This turns out to be some staggering incompetence on the part of Toshiba (or, more likely, their third-party vendor) - they managed to leave the signing key out of the database that's used to validate binaries, and managed to leave the signature database signing key out of the database that's used to provide whitelist or blacklist updates. The good news is that this is a blatant violation of Microsoft's Windows 8 certification guidelines, and that seems to have encouraged Toshiba to actually fix their BIOS. The bad news is that any of the affected machines that are currently available are still broken, and Toshiba don't seem to be willing to actually give you the firmware update yet."
Finally, and more troubling, some Lenovo PCs with UEFI Secure Boot aren't simply checking the proper keys to see if an operating system should be allowed to boot, but are also checking to see if an operating system is saying if it's "Windows" in its descriptive text. If the text doesn't say Windows, even if it is Windows 8, it won't boot. As Garrett says, "This is, obviously, bizarre." This problem has been known since November, and, Garrett's sole recommendation is "drinking, because as far as I know they haven't actually got around to doing anything useful about this yet."
James Bottomley, Parallels' CTO of server virtualization, well-known Linux kernel maintainer, and the man behind the Linux Foundation's efforts to create an easy way to install and boot Linux on Windows 8 PCs , is reporting some useful work is being done with the.
Bottomley was sorry to report that the proposed "Pre-BootLoader wouldn’t work in its current form with Gummiboot." Gummiboot is a small and simple bootloader that's designed to take "advantage of all the services available in the UEFI platform instead of being the massive link loader that things like grub," the popular multi-boot loader.
"Unfortunately this means that it boots kernels using BootServices->LoadImage()," Bottomley explained, "which means that the kernel to be booted is run through the UEFI platform secure boot checks. Originally Pre-BootLoader, like PE/Coff [Portable Executable and Common Object File Format] link loading to defeat the secure boot checks. Unfortunately, this means that something run by the Pre-BootLoader must also use link loading to defeat the secure boot checks on anything it wants to load and thus, Gummiboot, which is deliberately not a link loader, won’t work under this scheme.", was written to use
To get it to work, Bottomley had re-architect and re-write the bootloader. "The problem has now gone from being how do we create a Microsoft signed link loader that obeys their policies to how do we enable all children of the bootloader to use BootServices->LoadImage() in a way that obeys their policies. Fortunately, there is a way to intercept the UEFI platform signing infrastructure by installing your own security architecture protocol."
"Unfortunately," Bottomley continued, "the PI [Platform Initialization] Spec isn’t actually part of the UEFI specification, but fortunately it is implemented by every Windows 8 system that I can find. The new architecture now Intercepts this protocol and adds its own security check. However, there’s a second problem: While we’re in the security architecture protocol callback, we don’t necessarily own the screen of the UEFI system, making it completely impossible to do a present user test for authorizing the running of the binary. Fortunately, there does exist a non-interactive way of doing this and that’s the SUSE MOK [machine owner key] mechanism (https://www.suse.com/blogs/uefi-secure-boot-details/). Thus, the Linux Foundation Pre-BootLoader has now evolved to use the standard MOK variables to store hashes of authorized binaries."
So, the bottom line is that you can now use the "pre-BootLoader with Gummiboot. To boot, you have to add two hashes: one for Gummiboot itself and one for the kernel you’re booting, but actually this is a good thing because now you have a single security policy controlling all of your boot sequence. Gummiboot itself has also been patched to recognize a failure due to secure boot and pop up a helpful message telling you which hash to enroll."
The Linux Foundation final fix is still a few weeks away. At the linux.conf.au conference in Canberra, Australia, Bottomley said, in his presentation UEFI Secure Boot: Where we stand (PDF Link) that the Foundation submitted the fixed bootloader to Microsoft on January 21. Under Windows 8 Secure Boot, all PCs, no matter what operating system they actually run, must include several Microsoft-owned keys. Bottomley expects Microsoft to sign the Linux Foundation's bootloader with the appropriate keys within the next few days.
When you put it all together, it's clear that Linux has been making progress in working with Windows 8 PCs equipped with UEFI Secure Boot. That said, it's also clear that getting Linux to install and boot on a Windows 8 PC is still a major nuisance.