Secure Boot, Microsoft's implementation of UEFI, has been a cause of concern for Linux users ever since it was announced in January 2012. We've looked at it a few times before, but as the dust is still settling, we've decided to revisit it.
But before we get ahead of ourselves, let's go back to the beginning and find out exactly what Secure Boot is.
Prior to 2012, all PCs booted using BIOS. This was a relic of the 80s that many manufacturers miss-implemented, which lead to a kludgey kind of system that was held together by the digital equivalent of gaffa tape. It worked, but only because of the hard work of developers who could have spent their time coming up with much cooler things than boot interfaces if they weren't fiddling around trying to make the darned things work more smoothly.
So when Microsoft started to talk with manufacturers about the possibility of replacing the old system, everyone was quite glad of the impending demise of BIOS.
UEFI is, in many respects, a far superior system. It gives the boot programs more space to work in, and can better support more modern hardware. If it had all been left there, most people would have been happy.
However, it wasn't. They tinkered. They had to go a step further and added Secure Boot. This is an extension to UEFI that restricts booting to just systems that have been cryptographically signed using a trusted key. And the sting in the tail: Microsoft controls the master key. Crafty.
Of course as we know, this little addition doesn't make it completely impossible for Linux to boot on Secure Boot systems, it just makes it a bit tricky.
Of course it would be easy to claim that it's all just a cynical attempt by Microsoft to further tighten its hold on the PC industry - and there are a good many people who hold that particular view.
However, it is based on a genuine security risk that can be found in Windows: boot sector viruses. This is a class of malware that infects the Master Boot Record (MBR) that sits at the start of a disk. When the user boots up, the BIOS runs the code in the MBR. If all is well, in a correctly running system, this then boots the operating system. However, a boot sector virus can hijack this process and run some malicious action before booting the OS.
Under the Secure Boot system, the system will only boot signed code, so in principal such viruses won't be able to boot. Sounds good, right? Well, there are a couple of not insignificant problems with it.
Firstly, it relies on a single key, and historically single keys have not been able to stay secret for long (remember when PlayStation and Blu-ray keys were secret?). Secondly, and perhaps more importantly, boot sector viruses were common back in the days of MS-DOS. The world has moved on a fair bit since then, and malware writers are no exception.
Secure Boot is a huge upheaval to solve a problem that was dying out on its own. Frankly, there are far more pressing security concerns for Windows that are completely unaffected by it.
So, it's not likely to have an impact on the world of malicious software on Windows. It's also not particularly effective at locking other operating systems out of PCs. In the Windows 8 Hardware Certification Guidelines, Microsoft state:
"17. Mandatory. On non-ARM systems, the platform MUST implement the ability for a physically present user to select between two Secure Boot modes in firmware setup: "Custom" and "Standard". Custom Mode allows for more flexibility as specified in the following: a. It shall be possible for a physically present user to use the Custom Mode firmware setup option to modify the contents of the Secure Boot signature databases and the PK. This may be implemented by simply providing the option to clear all Secure Boot databases (PK, KEK, db, dbx), which puts the system into setup mode.