There is, however, another way that's only just been released, and at the time of writing, isn't used by any distros. However, since it doesn't involve a distro getting anything signed, we expect that it will quickly become the preferred method of choice for smaller or non-commercial Linuxes. This method uses a pre-bootloader similar to the shim that's been developed by the Linux Foundation. It's also signed by Microsoft's key, but instead of using distribution-specific keys, it uses user-added hashes. This means that when a user updates their kernel, they'll have to add a new hash to the pre-bootloader's database.
In principal this could be done automatically, but that would break the chain of trust that the signatures create. This should, in theory, be as simple as the user pressing a key to confirm that they want to do this. However, this has to happen at bootup, so it can't be automated. The chain of trust is then preserved because it's the action of a physically-present user and can't be done by some malware. It is hoped that in future releases, the shim and the Linux-Foundation's pre-boot loader can be combined so that a single pre-boot loader can be used across multiple distros.
How does it work?
The final thing we'll look at is how well all this works in practice. To be honest, we didn't have terribly high hopes when we received a Windows 8 PC. We downloaded a selection of distros, burned them to DVDs, and started battle.
So we were presently surprised to find that, by and large, things just worked. Or at least they did if you selected the default options. On Ubuntu, OpenSuse and Fedora we were able to install on our Secure Boot enabled PC without having to fiddle with keys, boot loaders or anything else, for that matter. However, we had some problems when we tried to create custom partitions on the disc, or dual boot.
When it was announced, many people thought Secure Boot would lock Linux out of PCs. Fortunately, that just isn't the case, and a number of major distributions already support this system. Many more are likely to support it soon now that the Linux Foundation's pre-boot loader is ready to be used. We can only hope that these solutions continue to work with future versions of Secure Boot.
During this article, we've casually skipped over one of the biggest restrictions of Secure Boot. That is, the requirement that it can't be disabled on ARM systems. We can look at this a few different ways.
We could casually ignore it since there are so few Windows RT machines available - and regardless of Secure Boot, few people seem inclined to buy them. We could also point to the fact many of the currently best-selling (pre-Windows 8) ARM machines have locked bootloaders (iPad and iPhone among them).
We could even suggest that many of the best-selling ARM computers that aren't phones or tablets have unlockable bootloaders (Chromebook, RaspberryPi). All these come together to make the case that we don't need to be worried about Secure Boot being locked on ARM machines.
But there is another angle to it all. Microsoft probably couldn't have insisted that manufacturers lock the boot loader on x86 machines. In the EU at least, this would almost certainly be construed as abusing a dominant market position, and that has got Microsoft in trouble before.
With ARM though, they don't have a dominant market position so are legally free to abuse their non-dominant position as much as they wish. With this in mind, some people have speculated that Secure Boot on ARM is what Microsoft want to do, and on x86 it's what they've been forced to do.
In the future, these people speculate, the x86 version will creep closer and closer to how it is on ARM until it finally locks users out of their own computers.
Cathy Malmrose, CEO of ZaReason, is one such person, and she spoke with us recently. Take a look at the interview for her views on the subject.
For now, though, Linux works perfectly well on both x86 Windows 8 machines - but we're still going to keep a very close eye on how Secure Boot changes in future versions.
