From Fedora Project Wiki
m (moved User:Pjones/Features/SecureBoot to Features/SecureBoot: Doesn't need to live under my user page any more.)
No edit summary
Line 111: Line 111:
* See [[Talk:Features/SecureBoot]]
* See [[Talk:Features/SecureBoot]]


[[Category:FeaturePageIncomplete]]
[[Category:FeaturePageReadyForWrangler]]
<!-- When your feature page is completed and ready for review -->
<!-- When your feature page is completed and ready for review -->
<!-- remove Category:FeaturePageIncomplete and change it to Category:FeatureReadyForWrangler -->
<!-- remove Category:FeaturePageIncomplete and change it to Category:FeatureReadyForWrangler -->
<!-- After review, the feature wrangler will move your page to Category:FeatureReadyForFesco... if it still needs more work it will move back to Category:FeaturePageIncomplete-->
<!-- After review, the feature wrangler will move your page to Category:FeatureReadyForFesco... if it still needs more work it will move back to Category:FeaturePageIncomplete-->
<!-- A pretty picture of the page category usage is at: https://fedoraproject.org/wiki/Features/Policy/Process -->
<!-- A pretty picture of the page category usage is at: https://fedoraproject.org/wiki/Features/Policy/Process -->

Revision as of 17:09, 22 June 2012

Stop (medium size).png
DRAFT
This is just a DRAFT. We try and make sure the information here is up to date and correct, but please check before depending on it.

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

Current status

  • Targeted release: Fedora 18
  • Last updated: 01-Jun-2012
  • Percentage of completion: 50%
Sub-task Percent Complete Owner Notes
pesign 90 pjones pesign is written (cert generation needs work)
authvar 10 pjones not strictly necessary for initial support
shim 90 mjg59
kernel 30 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 90 pjones I think what we've got now has a good chance of working
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

Big sky.

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

Release Notes

Probably should write one, yeah.

Comments and Discussion