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

No notes for slide

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

  1. 1. Secure Boot and LinuxFrédéric CrozatSenior Software Engineerfcrozat@suse.com
  2. 2. Secure Boot: an introduction
  3. 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. 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. 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. 6. Secure Boot: SUSE solution
  7. 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. 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. 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. 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. 11. Implementing Secure Boot support for<insert your favorite distro name here>
  12. 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. 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. 14. Bootloaders • Shim loader • Grub2 needs to talk to shim loader check kernel signature14
  15. 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. 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. 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. 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. 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.efi19
  20. 20. Efitools: the “ultimate” solution ?
  21. 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. 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. 23. Questions ? Thank you.23