Mon-3-Mar, 11:15am, Ard Biesheuvel

LCA14-105: UEFI Secure Boot

• NOT: a way to lock down your TiVoUEFI Secure Boot does not prevent the user from manipulating the boot environment:• ‘BIOS’ menu or EFI shell may still be available• kernel command line can be persistently

modified (by root)• NOT: a way to keep secrets on the target

• if your kernel binary contains special sauce that you prefer to keep secret, you need something else

UEFI Secure Boot, what it is not

The primary purpose of UEFI Secure Boot is

to prevent exploits from gaining persistenceby corrupting the boot environment

This is accomplished by allowing only signed EFI applications to be executed:

• EFI-stub kernel images• (n+1) stage bootloaders (GRUB)• option ROMs

So what is UEFI Secure Boot?

• Covered by UEFI Secure Boot authentication:• the next boot stage (kernel, GRUB, etc)• authenticated variable store (e.g., updating the root

certificate using UEFI runtime services)

• NOT (currently) covered by UEFI Secure Boot• authentication of UEFI/Tianocore itself• (n+2) stage bootloader (i.e., GRUB verifying the kernel)• command line passed to next stage• FDT blob• initrd image• Kexec

Scope of UEFI Secure Boot

Current status:• proof of concept implementation available for

QEMU/Vexpress• requires EFI stub patches that are not yet upstream• requires an updated sbsigntool that allows signing of ARM and

arm64 PE/COFF images (available in Linaro Overlay repository)• instructions can be found here: https://wiki.linaro.

org/ardbiesheuvel/UefiSecureBootPrototype• Tianocore Authenticated Variable Store needs porting to

TrustZone/Secure World• if the Secure World ‘owns’ the WRITE_ENABLE pin of the NOR flash,

it should also perform the authentication of the signed variable updates itself

UEFI Secure Boot on ARM

• device tree images (FDT)• direct control over internal plumbing of the kernel => security hole• trusted by the kernel, so it needs to be authenticated by the boot

loader• implicit => e.g., part of UEFI binary itself• signed updates through TrustZone• reuse authenticated variable store?

• allows standardised update mechanism through runtime services• kernel command line

• updatable by root through efibootmgr (unauthenticated)• powerful controls over kernel internals• may need to be sanitized in the EFI stub or next stage bootloader

• authentication through runtime services• GRUB and Kexec calling into UEFI Secure Boot protocol handler

• what about initrd images??

UEFI Secure Boot on ARM

• Linaro will not act as a root CA for UEFI Secure Boot on ARM systems• single root CA == single point of failure!• hardware A running distro X and hardware B running distro Y have no

purpose for a shared cert authority between them• No need for a shim on ARM systems

• it is up to the vendors to decide whether to ship systems in Setup Mode or with some Platform Key pre-installed

• no bully in our playground who imposes incompatible rules for everyone

Certificate management

• Crypto routines for image verification are used in two ways• Verification of signed EFI applications (GRUB, kernel)• Verification of signed variable updates

• Secure design calls for handling of the latter to reside completely in the secure world• Needs secure world interface to pass unchecked variable updates• Needs secure world interface to reuse secure world routines to

authenticate EFI application• is needed to avoid duplication of authentication routines and variable

access routines in both worlds

TrustZone Secure World integration

Proceed with prototype• image authentication using runtime services, either

from GRUB or from the kernel (kexec)• investigate how to handle initrd and command line • anything else?

Next steps

More about Linaro Connect: http://connect.linaro.orgMore about Linaro: http://www.linaro.org/about/

More about Linaro engineering: http://www.linaro.org/engineering/Linaro members: www.linaro.org/members