Your SlideShare is downloading. ×
Distro Recipes 2013: Secure Boot and Linux: several issues, one solution
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Distro Recipes 2013: Secure Boot and Linux: several issues, one solution


Published on

Published in: Technology

  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1. Secure Boot and LinuxFrédéric CrozatSenior Software
  • 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 dont 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 panacea4
  • 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 cant 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 modules8
  • 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 modules10
  • 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 signature14
  • 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 modules15
  • 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 variables16
  • 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 implies17
  • 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 kernel18
  • 19. “Legal paperwork” • What is required to be signed by Microsoft (acting as UEFI Signing Service): ‒ Developer account at ‒ 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.efi19
  • 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 based21
  • 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