http://distro-recipes.org

1. Secure Boot and Linux
Frédéric Crozat
Senior Software Engineer
fcrozat@suse.com

2. 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 :)
3

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
4

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>).
5

6. 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.
7

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
8

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.
9

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
10

11. 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)
12

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)
13

14. Bootloaders
• Shim loader
• Grub2 needs to talk to shim loader
check kernel signature
14

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
15

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
16

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
17

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
18

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
19

20. 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
21

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)
22

23. Questions ?
Thank you.
23