State of Secure Boot detailed

Red Hat and Fedora developer Matthew Garrett has detailed the "range of subtle changes" that have taken place since he began working on Secure Boot support. In a blog posting, Garrett gives an overview of the current implementation. He explains that the current approach, a shim bootloader, "cunningly called 'Shim'", contains a public key under their own control and is signed by Microsoft. The shim will only boot binaries signed with the public key and allows the developers to build and sign all other binaries themselves without going back to Microsoft to get bootloaders or other components signed.

Garret points out that a locked-down boot environment and signed kernel do block modified bootloaders and booting attack code, but do nothing if, for example, an attacker uses a booted kernel to launch another kernel. To ensure that doesn't happen, direct hardware access from userspace is blocked and must go through kernel modules which have been signed by a key the kernel trusts.

SUSE has assisted the process by developing useful elements such as a simple mechanism to allow new keys to be enrolled from within a booted operating system, avoiding reliance on what is expected to be the variety of inconsistent user interfaces from PC firmware makers.

To assist other distributions, the shim will also notice if the second stage bootloader is signed with a key it doesn't recognise. If it is, users will have the option of enrolling a new key from install media and having it added to a trusted key list. There is also, now, the capability to deactivate signature validation in the shim so developers need not sign kernels they are developing; it requires a reboot and a user generated password to be activated.

Despite the concern over ARM-based Windows 8 tablets being completely locked down by Secure Boot, Garrett says there are no plans to support Secure Boot on ARM. In part this is due to the inability to disable Secure Boot on ARM, and also because its not expected that the signing key for third party UEFI binaries will be present on those devices.

According to Garrett, SUSE and Fedora will be shipping the same Shim code while Ubuntu is currently shipping an older version of the same code. He expects them to add the local key management code in the next release but also says that Ubuntu's other significant difference is that it doesn't require kernel modules to be signed. This difference means Ubuntu is potentially vulnerable to the attacks outlined by Garrett, but until there is an attack of that kind, there is no case for revoking keys.

For those interested in a more technical background, Garrett followed up with a detailed description of how the shim bootloader works and had previously offered a guide to UEFI development.

(djwm)