Features/SecureBoot

UEFI Secure Boot

Summary

"Secure Boot" describes a UEFI feature by which malware is prevented from inserting itself into the boot process before the operating system loads. The UEFI feature is required to be enabled on all machines bearing the Windows 8 Client logo, which will be the overwhelming majority of all desktop and notebook systems.

This feature proposal describes an implementation of necessary components for Fedora to boot and install under the industry de facto standard UEFI Secure Boot environment.

Owner

• Name: Peter Jones
• Name: Matthew Garrett

Current status

• Targeted release: Fedora 18
• Last updated: 15-Oct-2012
• Percentage of completion: 99%

Sub-task	Percent Complete	Owner	Notes
pesign	99	pjones	pesign is written (cert generation needs work)
shim	99	mjg59
kernel	99	mjg59	In-tree signed modules are deployed in rawhide. Remaining items are getting previously mentioned support upstreamed importing signatures from UEFI into the _modsign keyring to allow modules signed with a vendor key to work implementing cap checks to limit access when SB=1 (e.g. no userspace PCI access, etc) (possibly) support detached signatures for modules and/or firmware
grub2	99	pjones	I think what we've got now has a good chance of working
lorax	99	pjones	patch is approved; waiting on shim package
anaconda	99	pjones	patch is approved; waiting on shim package
rel-eng stuff	?

Detailed Description

Systems with UEFI Secure Boot enabled will ship with a set of vendor-determined keys installed in the firmware. These keys include the ability to boot from binaries signed by the signing service hosted by Microsoft. This feature includes simultaneous support for two methods of booting under this scheme. Under the first scheme, Fedora will utilize the signing service hosted by Microsoft. Under the second, a site will create their own keys and deploy them in system firmware, and will do their own signing of binaries with it. In both schemes, shim, grub2, 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 it. Additionally, grub2 will operate with similar restrictions as it would if you had set a supervisory password in your configuration. 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 loaded modules for signatures and refuse to load them if they are unsigned, and it will refuse any operations from userland which cause userland-defined DMA.

Scheme the first

Under this scheme, the signing service will be used to sign a first-stage bootloader, shim, which holds a Fedora-specific public key. shim will then validate against the Fedora-defined key referenced above.

Scheme the second - "custom mode"

In this scenario, an administrator who requires a local root of trust may generate their own keys using openssl, on an administrative machine, with instructions that will be provided. The administrator then builds a custom version of shim and signs it with the pesign tool, and optionally builds and signs their own versions of grub and the kernel. The administrator then sets the system into what UEFI defines as "setup mode" and installs the OS, and then uses the sbsetup tool[1] provided by pesign to enrol their keys in the firmware.

[1] we may also provide kickstart bits to do this part. Utilities to sign bootloaders on writeable install media may be provided later.

Benefit to Fedora

Hardware enablement for nearly all future "client" hardware.

Scope

See the table at https://fedoraproject.org/wiki/Features/SecureBoot#Current_status

Also effected:

• Userspace drivers that require dma-level access (i.e. non-KMS graphics drivers) won't work (mostly effects via)
• setpci won't work in secure mode
• security processes need to be determined

Test Plan

UEFI-capable systems with Secure Boot features are available from a number of vendors under NDA. Those with access to such systems are actively solicited to perform testing. On UEFI systems without Secure Boot support it may be possible to fake it with some cleverness, but that's TBD.

The test methodology is simple - enable secure boot, try and install and boot the system, and see if it works. For "custom mode", it's essentially as described above.

• Architectures:

X86_64

• Manufacturer's Platforms:

All who are interested in support for their hardware. Note that only very new platforms support UEFI 2.3.1 .

• Each platform should be able to install and boot from:
  • Internal disk
  • External disk connected by FC
  • USB CD
  • USB DVD
  • Other USB storage devices TBD
  • Network devices

User Experience

Significantly similar to that of today. The EFI Boot Manager, which runs in the BIOS, is a new feature, which can be frobbed at runtime using efibootmgr.

Dependencies

• Vendor support in hardware
• Signing service (announced 31-May-2012)
• Binary signing support in koji
  • Needs to sign the grub2 and kernel binaries
  • Hardware crypto key device (?)
• Signed module support in the kernel
  • Support for in-tree signed modules
  • Possible support for 3rd party modules signed with a key enrolled in the UEFI DB

Contingency Plan

Gin. We may do that anyway.

Documentation

• http://www.uefi.org
• https://www.tianocore.org/
• http://msdn.microsoft.com/en-us/library/windows/hardware/jj128256

Release Notes

Probably should write one, yeah.

Comments and Discussion

• See Talk:Features/SecureBoot