Secure Boot and Linux

Frédéric CrozatSenior Software Engineer

fcrozat@suse.com

Secure Boot: an introduction

3

UEFI ?

• For some years now, BIOS is being replaced by firmware following UEFI (Unified Extensible Firmware Interface) specification.

• It allows manufacturers to better cope with modern hardware and OS vendors to have a better interface to manage it.

• BIOS compatibility can still be available with CSM (Compatibility Support Module) but this will disappear in the near future.

• Some UEFI implementations even have a shell :)

4

Secure Boot: what is it ? Why now ?

• It is a way to prevent pre-OS attack (before bootloader is started), to ensure bootloader and kernel are trusted and not run by a Bootkit

• We don't envision Secure Boot as a requirement for servers within the next 3 years

• We expect a majority (if not all) of new desktop systems to be shipped with Secure Boot enabled by default (requirement for Windows 8 Desktop)

• Secure Boot can be useful for secure servers against boot viruses but not a panacea

5

What Secure Boot implies

• OS must be signed and its signature accepted by UEFI firmware

• To get OS “signature” accepted by UEFI firmware, we need to either:

‒ Inject manually key in firmware (not user friendly)

‒ Use a distribution whose key has been integrated by hardware vendor or signed by UEFI Signing Service (Microsoft is acting as this service).

• To ensure Secure Boot can't be easily circumvented, some kernel features can be disabled when running under Secure Boot (distribution policy, to be discussed <insert your troll here>).

Secure Boot: SUSE solution

7

Our solution to Secure Boot 1/2

• Secure Boot enforces signature on the pre-OS boot environment.

• This signature process should still be in the hands of distribution (SUSE/openSUSE) and users.

• To allow this modularity, SUSE expanded shim loader (EFI application, created by Matthew Garrett to handle Secure Boot for Linux) to give back freedom to users and prevent locked-in.

8

Our solution to Secure Boot 2/2

• Shim loader is signed by UEFI

Signing Service and SUSE

• It will verify grub2 is signed by SUSE

or a key enrolled by user, called

Machine Owner Key (MOK)

• Then grub2 will boot and do similar

check on kernel

• And kernel will do the same on

modules

9

Machine Owner Key (MOK)

• Enroll key from the OS (with a password for MOK list), using mokutils tool.

• Rebooted is required, where shim will check password: ensure physical user is present.

• This key is added to MOK list, saved into in an UEFI Boot Service Only Variable and will be used for future boots to ensure key is not modified.

• MOK list can only be modified in Secure Boot phase (before kernel is started).

• Enroll can also be done at boot time if key is available on EFI System Partition.

10

Restrictions in Secure Boot mode (SP3 only, not relevant for openSUSE)

• A controversial topic, at minimal :)

• SP3 will have basic enablement for Secure Boot, but will have some gaps (mostly for servers):

‒ Kexec / Kdump are disabled

• No direct access to IO port, must use kernel interface

‒ KMS drivers are required for graphics card

• No direct access to memory‒ No /dev/mem, no /dev/rmem

• Not possible to load unsigned 3rd party modules

Implementing Secure Boot support for <insert your favorite distro name here>

12

Kernel bits 1/2

• Convert kernel as a EFI executable (EFI Stub) => UEFI firmware could boot kernel without bootloader

• UEFI variables access from kernel

• UEFI clock support (not required)

• UEFI getvideomode (flicker-free boot) (not required)

• UEFI reboot (not required)

• KMS drivers (already done in openSUSE)

13

Kernel bits 2/2

• Sign main kernel

• Sign all in-tree kernel modules

• Generate a “per build” kernel private key to sign out of tree kernel modules

• Kexec / kdump must be Secure Boot aware

• Xen hypervisor need to be Secure Boot aware

• Kernel should check its signature (and modules signature against bootloader)

14

Bootloaders

• Shim loader

• Grub2 needs to talk to shim loader

check kernel signature

15

Build Service

• Secure store private key to sign shim loader

• Store private kernel build key outside build tree for later user

‒ Allow this private per-build key to be used for out of tree modules

16

Userspace

• xf86-video-modesettings (for non accelerated KMS drivers, like cirrus, aspeed, mga g200)

• Modutils / kmod supports for signature on kernel modules (display them, verify them)

• Tool to sign kernel / modules (pesign)

• Tool to manipulate UEFI keys and variables

17

Installer

• Installer DVD image should be Secure Boot aware (shim + grub2 should be used)

• Installer should also have some kind of signature checking (for stage 1, 2..) ?

• When started, installer should warn user it will install in Secure Boot mode, and what it implies

18

Into the key business

• Kernel and bootloader must be signed :‒ <distro> Certificate Authority (best to separate it from the

one used for package signature). Will be embedded in shim loader, to validate signature

‒ signing key (not a GPG one but a X.509 RSA 2048). This key will be used to sign bootloader (grub2) and kernel

19

“Legal paperwork”

• What is required to be signed by Microsoft (acting as UEFI Signing Service):‒ Developer account at https://sysdev.microsoft.com/

‒ AuthentiCode certificate (discount at $99 for the first year), which will be used to sign binary to Microsoft (might requires some notarised ID)

‒ Sign (electronically) Microsoft Logo Program Testing Agreement v3 + UEFI Firmware Agreement

‒ Sign a test .exe with AuthentiCode certificate and send it to Microsoft

• Once it is done, you will be able to send .efi file (ie shim.efi) to Microsoft for signature:‒ Create a .cab file containing shim.efi (with lcab)

‒ Sign it with your AuthentiCode certificate (with osslsigncode)

‒ Upload it on Microsoft website (with Silverlight :(

‒ Wait

‒ … Wait..

‒ Retrieved a new .cab file containing signed shim.efi

Efitools: the “ultimate” solution ?

21

Efitools

• James Bottomley, under Linux Foundation umbrella, has been working on another solution for Secure Boot: efitools.

• Current solution aka PreBootloader (shim) is bypassing most of UEFI services (BootService->LoadImage) and do not work with new generation of bootloader (gummiboot)

• James is proposing an “plugin” which will add its own security check.

‒ Pro: It had MOK support with this : only hash based, not certificate based

‒ Con: rely on Platform Infrastructure Spec, which is not part of UEFI spec (but is present in all tested Windows 8 systems around) ; only hash based, not certificate based

22

Summary

• With shim, we are able to get Linux running on today shipped systems, without compromising security.

• MOK handling allows flexibility for testing, upgrading and 3rd party support

• In the long term, shim and efitools will merge (already announced by both parties)

Thank you.

23

Questions ?