• SecureBoot

Introduction

This page contains information about enabling FreeBSD to boot on UEFI systems where Secure Boot has been enabled.

Secure Boot requires that all boot-time code prior to the UEFI ExitBootServices call, be signed by a private key whose public key counterpart is known to the boot firmware.

Currently the only key that is guaranteed to be present in any given system is Microsoft's.

Additionally, to be certified for the Windows 8 logo program, systems must be have Secure Boot enabled, although they must provide a way to disable it and they must allow the user to add keys to the system. Microsoft also provides a service where binaries can be forwarded to them for signing with their key.

Existing Implementations

Fedora

The Fedora approach is detailed here.

In short, Fedora uses a boot shim which is signed using Microsoft's key. This shim then loads GRUB2, verifying it against a Fedora-issued certificate contained in the shim. GRUB2 boots in a locked down mode and loads the Linux kernel, verifying its signature against the Fedora key and enforcing certain constraints against any arguments provided to the kernel. The fact that boot occurred under Secure Boot is flagged.

During runtime, the Linux kernel will refuse to load modules that are not signed and will also refuse to allow any operation that would allow user-initiated DMA.

Ubuntu

The Ubuntu approach is detailed here.

In short, Ubuntu uses the same shim as Fedora but instead of using GRUB2, it loads a customised version of Intel's efilinux loader which then loads the kernel. Ubuntu takes a much more relaxed reading of the UEFI Secure Boot guidelines in that they have decided that since the restrictions only pertain to code executed prior to the ExitBootServices there is no need to perform verification of the kernel or restrict its operation post-boot.

Proposals for FreeBSD

Matthew Garrett's shim loader (source on Github), as used by both Ubuntu and Fedora, is under a license that appears to be compatible with the BSDL. I believe we should adopt this approach and use it to load a signed version of FreeBSD's EFI loader. The FreeBSD project should obtain a key, held by the FreeBSD Foundation, to use in verification and it should be used to sign releases.

In terms of whether we follow Fedora's locked-down runtime approach or Ubuntu's less restrictive approach, I believe we should permit both.

For a first stage, we should acquire the necessary keys and develop the necessary code to allow a system to boot using a Microsoft-signed shim and a FreeBSD-signed EFI loader. We should also users to generate their own keys, enrol them in the firmware and sign their own shim and/or loader.

The second stage would be to allow kernels and kernel modules to be signed and to permit the system to be fully locked down as per the Fedora approach. I believe this should be optional but supported. Additionally, certain elements could be enabled or disabled but only by a signed loader configuration. It may be worth investigating whether the user-facing components of this could be done using TrustedBSD MAC.

Contact

• EdwardTomaszNapierala

• EdMaste

Repository

There is no code for this project yet as it is still in the planning stages.

Tasks

Additional Resources

• FreeBSD Foundation: FreeBSD UEFI Secure Boot

• The Linux Foundation: Making UEFI Secure Boot Work With Open Platforms (PDF)

• Adventures in Microsoft UEFI signing

• Signing UEFI Drivers and Applications for UEFI Secure Boot

• Microsoft: Windows Hardware Developer: File signing LSA plugins and UEFI firmware

• Microsoft: Hardware Dev Center: UPDATED: UEFI Signing Requirements

CategoryTodo CategoryProject CategoryStale