Download - LCA14: LCA14-105: UEFI secure boot
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