Product SiteDocumentation Site

3.2. Shim

Fedora uses a first-stage boot loader called shim which embeds a self-signed CA certificate. This CA is then used to verify the GRUB 2 boot loader (UEFI version, a PE/COFF program signed with AuthentiCode). Before booting a kernel, GRUB 2 calls back into shim to verify the AuthentiCode signature of the kernel.
In addition to the Microsoft key, shim also supports additional trusted certificates provided by the owner and a mechanism to disable signature verification. The information is kept in UEFI variables which cannot be written after an operating system has booted. Shim contains a physical presence check and asks for confirmation before it updates the settings stored in these UEFI variables.
In Fedora there are two packages that make up shim. The package named "shim" is the result of compiling the source code that makes up shim. This package will not boot the system as it is not signed. The results of building the shim package are signed, then incorporated into the shim-signed package. The shim-signed package contains the signed binary that is capable of booting the system.
The shim package also contains a blacklist of known bad keys or binaries that should not be allowed to boot. The blacklist is a file called dbx.esl in the shim package. This blacklist is currently embedded into the shim binary at build time. It exists to prevent a known exploitable version of grub from being booted. Future developments may see this blacklist moved into UEFI memory. In its current form, updating the blacklist will not provide additional security as you could downgrade the shim package to avoid updating the blacklist. If the blacklist is stored in the BIOS, a blacklist update would survive a shim downgrade.
Additionally there is a blacklist which Microsoft maintains, signs, and is stored in the BIOS for checking. Microsoft will provide this list to Fedora Project for inclusion. This may create periodic updates to the shim-signed package that do not change the actual shim binary. This blacklist file does not currently exist as nothing has been blacklisted. The blacklist will likely be packaged on its own to avoid having to update the shim-signed package.
The details about this blacklist come from Microsoft and Fedora Project is not able to update this blacklist. The data is signed with a Microsoft key which will prevent unauthorized updates to this list. Microsoft has suggested that the blacklist is to be used to prevent the computer from booting compromised keys and known vulnerabilities.
In both boot methods, shim, GRUB, and the kernel will detect that they are started in what UEFI describes as "User mode" with Secure Boot enabled, and upon detecting this they will validate the next stage with a Fedora-specific cryptographic public key before starting. The validation is done via shim for GRUB, and GRUB calls back to shim to validate the kernel as well. Once the kernel is booted, it will also detect that it is in Secure Boot mode, which will cause several things to be true:
it will validate the boot command line to only allow certain kernel settings
it will check modules at load time for signatures and refuse to load them if they are unsigned or signed with a signature not found in the UEFI key store variables (see note)
it will refuse any operations from userland which cause userland-defined DMA.
disable support for hibernate/suspend-to-disk, and other features which would allow executing arbitrary code in kernel mode (even for the root user).
Additional information on shim can be found on the shim development repository.

Note

Other distributions have chosen to not require signed kernel modules in their Secure Boot implementation. Fedora believes that to fully support Secure Boot this is required. We are working to limit the impacts of this while ensuring that untrusted module code is not allowed to execute.