When the Linux Foundation announced that it was creating its own UEFI boot solution, it seemed that our woes about not being able to install Linux on Secure Boot systems would soon be coming to an end. While the "pre-bootloader" is still not production-ready, it's been readily worked on, and recently experienced some significant changes.
One of the most important goals of this pre-bootloader is that it'd be able to operate with any primary bootloader just fine, such as GRUB. However, due to design choices, the Gummiboot bootloader was simply incompatible. This is a bootloader that's specifically designed to be as lightweight as possible while still being able to take advantage of all that UEFI and its Secure Boot features offer. Simply put, the pre-bootloader's inability to function with Gummiboot was simply unacceptable.
The reason for the lack of interoperability is that Gummiboot's design allows operating systems to boot via the Secure Boot mechanics, whereas the pre-bootloader's design bypassed that - as we previously discussed. Through the use of UEFI call interceptions and the adoption of SUSE MOK, the pre-bootloader now supports Gummiboot and others just fine. The design, while reasonable, seems a little complex. Microsoft sure has created a lot of work for developers and headaches for those trying to comprehend it all with its insistence of Secure Boot. I'm sure I'm not alone in anticipating the day when this pre-bootloader is finally deployed in production OSes so that we can stop thinking about it!
In related news, the UEFI issue we talked about the other day that risked bricking select Samsung notebooks has been patched up. However, the special driver must be downloaded by itself and merged into the latest 3.7.5 kernel. This patch should make it into the 3.7.6 stable release.
Samsung still needs to address this in their UEFI implementation. It simply should not be possible to completely kill the system via software. If a Linux driver can brick a motherboard by poking certain values into memory, so can Windows malware.
Not that it should happen ANYWAY, but I'm wondering why none of these companies ever employ a dual-bios solution like is common on desktop motherboards. It shouldn't be THAT difficult (or expensive), and it could prevent this kind of thing from being able to happen.