From Fedora Project Wiki
No edit summary
 
(29 intermediate revisions by 4 users not shown)
Line 14: Line 14:
== Current status ==
== Current status ==
* Targeted release: Fedora 18
* Targeted release: Fedora 18
* Last updated: 01-Jun-2012
* Last updated: 10-Jan-2013
* Percentage of completion: 30%
* Percentage of completion: 100%


{| border="1"
{| border="1"
|- style="color: white; background-color: #3074c2; font-weight: bold"  
|- style="color: white; background-color: #3074c2; font-weight: bold"  
|Sub-task||Percent Complete||Notes
|Sub-task||Percent Complete||Owner||Notes
|-
|-
|pesign||100||pjones||
|-
|shim||100||mjg59||
|-
|kernel||100||mjg59||In-tree signed modules are deployed in rawhide.  Remaining items are
* getting previously mentioned support upstreamed
|-
|grub2||100||pjones||
|-
|lorax||100||pjones||
|-
|anaconda||100||pjones||
|}
|}


== Detailed Description ==
== 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 UEFI CA signing service.  This feature includes simultaneous support for two methods of booting under this scheme.  Under the first scheme, Fedora will utilize the UEFI CA signing service.  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
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.
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 =
=== Scheme the first ===


Under this scheme, the UEFI CA signing service will be used to sign a first-stage bootloader, [https://github.com/mjg59/shim shim], which holds a Fedora-specific public key.  shim will then validate against the Fedora-defined key referenced above.
Under this scheme, the signing service will be used to sign a first-stage bootloader, [https://github.com/mjg59/shim shim], which holds a Fedora-specific public key.  shim will then validate against the Fedora-defined key referenced above.


= Scheme the second - "custom mode" =
=== 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 [https://github.com/vathpela/pesign 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.
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 [https://github.com/vathpela/pesign 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.
Line 44: Line 56:
== Scope ==
== Scope ==


Big sky.
See the table at https://fedoraproject.org/wiki/Features/SecureBoot#Current_status
 
Also effected:<ul>
<li>Userspace drivers that require dma-level access (i.e. non-KMS graphics drivers) won't work (mostly effects via)
<li>setpci won't work in secure mode
<li>security processes need to be determined
</ul>


== Test Plan ==
== Test Plan ==
Line 72: Line 90:


* Vendor support in hardware
* Vendor support in hardware
* UEFI CA signing service (announced 31-May-2012)
* Signing service (announced 31-May-2012)
* Binary signing support in koji
* Binary signing support in koji
** Needs to sign the grub2 and kernel binaries
** Needs to sign the grub2 and kernel binaries
Line 87: Line 105:
* http://www.uefi.org
* http://www.uefi.org
* https://www.tianocore.org/
* https://www.tianocore.org/
* http://msdn.microsoft.com/en-us/library/windows/hardware/jj128256


== Release Notes ==
== Release Notes ==
Line 94: Line 113:
* See [[Talk:Features/SecureBoot]]
* See [[Talk:Features/SecureBoot]]


[[Category:FeaturePageIncomplete]]
[[Category:FeatureAcceptedF18]]
<!-- 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 -->

Latest revision as of 01:11, 11 January 2013

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: 10-Jan-2013
  • Percentage of completion: 100%
Sub-task Percent Complete Owner Notes
pesign 100 pjones
shim 100 mjg59
kernel 100 mjg59 In-tree signed modules are deployed in rawhide. Remaining items are
  • getting previously mentioned support upstreamed
grub2 100 pjones
lorax 100 pjones
anaconda 100 pjones

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

Release Notes

Probably should write one, yeah.

Comments and Discussion