The Kernel is signed with the Fedora CA key and is verified by shim before GRUB will allow execution. Modules the kernel loads are signed with a key that is generated at kernel build time, then destroyed.
The Kernel will import the UEFI key database and use that to verify Kernel modules. This means that 3rd party kernel modules signed with a key trusted by UEFI (Microsoft), will load in the Kernel while Secure Boot is enabled.
It is important to note that once the kernel loads the initial ramdisk (initrd), execution is no longer trusted. While the initrd may contain signed kernel modules, it also contains unsigned userspace code. The integrity of this code cannot be guaranteed.
Restrictions are in place to be fully compliant with Secure Boot. This requires us to prevent any execution of unverified code at the supervisor level. Most users won't notice these restrictions as most of the userspace packages that required such access have been fixed to work without it. There are, however, a few services or features that will not work in a Secure Boot enabled machine at this time. They include:
| kexec/kdump |
| hibernate (suspend to disk) |
| third party modules that are unsigned, or signed with an unknown key |
| systemtap kernel probing (and kprobes) |
In future iterations of Secure Boot support the above may also be possible, however secure implementations were not feasible in the Fedora 18 timeframe. If you require support of any of these features, Secure Boot must be disabled.
Currently, the Fedora shim was signed in a way that gives it an expiration date of October 2013, prior to the Fedora 18 end-of-life. We are not aware of any hardware that honors this expiration date, but it's not out of the question. This is the date Microsoft gave the signature, Fedora has no control over it. We are investigating this issue and expect to resolve it in the future.
