• DevSummit
• 201305
• UEFI

FreeBSD Developer Summit: UEFI

May 15, 2013 13:30-16:30 in SITE F0126

Overview

This working group was focused on how FreeBSD can adapt to the UEFI boot environment. It was open to anyone with an interest in the state of FreeBSD on UEFI and anyone who wished to be part of further discussions as to how FreeBSD on UEFI will look.

It may be possible to bring in people who cannot attend in person via video conference or chat tools. Notes during the session will be published later on for the whole community to see what we discussed.

Goals

In this working group I hope to update the developer community as to the state of support of UEFI under FreeBSD. This will be in the form of a brief presentation. After that a series of discussions will be held around certain topics with a view to determining future directions of UEFI support.

Topics

Attending

In order to attend you need register for the developer summit as well as by email for the session and be confirmed by the working group organizer. Follow the guidelines described on the main page or what you received by email. For questions or if in doubt ask the session chairs.

Please do NOT add yourself here. Your name will appear automatically once you have received the confirmation email. You need to put your name on the general developer summit attendees list though.

Notes & Results

This is not a direct transcript of the session, more a list of the outcomes of the discussions in the working group, issues that were discussed and the tasks associated with addressing them.

Loader and Early Boot

Currently we lack support for booting under UEFI systems. Code is present in the projects/uefi(archive.org) branch but needs some work before it can be merged back.

The general consensus of the working group is that our boot process should look something like this:

• First stage boot is an adaptation of Matthew Garrett's shim loader. This will be kept as simple and "pure UEFI" as possible to minimise the necessity for changes and thus re-signing. Its only job will be to perform signature validation and chain-loading of subsequent stages.
• Second stage boot is an analogue of gptboot. It will have understanding of common FreeBSD boot filesystem types and its job will be to load /boot/loader.efi from the boot filesystem. It will have some level of boot drive selection capability.
• Third stage boot is loader.efi. This will be a PECOFF image but will generally live on the actual FreeBSD filesystem.

The intent is that boot can begin at either of the stages listed above. If desired, loader.efi can be placed in the EFI System Partition and boot can begin directly from that point but the three-stage process listed above gives us a good default that will allow Secure Boot while minimising the need for frequent re-signing by third-parties (i.e. Microsoft).

The following issues exist:

• No i386 kernel support. The amd64 handoff process is much more streamlined than the i386 process, which can still (in theory) be directly booted. The proposed solution is to remove the direct boot support and make the i386 loader handoff process look more like the amd64 process, where the CPU is considerably more "set up" before the kernel is started. This will require some kind of flag to be provided to tell loader whether to use the older process or the new process. Once this is done, i386 can be taught to parse the EFI memory map and it should work.

• Clang doesn't support Microsoft calling conventions. UEFI uses Microsoft's calling conventions on amd64. GCC 4.6+ has the ability to flag a function call as using Microsoft calling conventions but clang currently does not. This is being addressed.

• The first stage (shim) and second stage boot code needs to be written.
• libstand. Libstand is currently built outside of sys/boot and built as 32-bit on amd64. Libstand should most likely move into sys/boot and its build process retooled to allow 32- and 64-bit variants to be built.

Kernel Fixes

The following issues exist:

• UEFI removes the VESA BIOS and we no longer have access to text mode. EFI's Graphics Output Protocol gives us access to the linear framebuffer and a basic driver for this is present in the projects/uefi branch but it needs work.

• The kernel needs to provide access to the UEFI runtime services in order to allow utilities to add boot entries, edit nvram variables and the like. This should be done in as architecture-independent way as possible.
• Currently we set the active flag in GPT protective MBRs. This is invalid behaviour and prevents boot under UEFI.

Installation

The following issues exist:

• The installer needs to be taught about creating EFI System Partitions (if needed) or selecting an EFI System Partition to install our first- and second-stage boot code.
• The installer needs to be taught about creating EFI boot entries for our boot code once the kernel has an API for this.

Secure Boot

The primary concern with support for Secure Boot is to ensure that anyone who attempts to install FreeBSD on a system with Secure Boot enabled can do so. The anticipated common scenarios are going to be either Secure Boot disabled or Secure Boot enabled with Microsoft's key present. The former will be supported with minimal change, the latter requires us to have a shim loader (see above) signed by Microsoft. We will also need internal signing certificates for the later stages of the boot process (up to and including loader.efi but not necessarily the kernel) and code to perform verification.

Later we can look at providing further optional support for people who want to construct secure, signed boot chains involving signatures all the way to the kernel and beyond to modules or even executables.

The following issues exist:

• Someone, most likely the FreeBSD Foundation, needs to engage with Microsoft to allow us to sign our shim loader.
• Someone, most likely the FreeBSD Foundation and/or secteam, need to work out what our policy is for managing our keys and generating bits for installation.

General Issues

The following issues exist:

• EFI loader code commonality. There is currently a level of copy/paste code between the various EFI loaders, which includes i386, amd64 and ia64. This should be addressed as much as possible.

CategoryHistorical