UEFI Secure Boot

James Bottomley

  • Each OEM has different way to turn off UEFI Secure Boot
  • OEM controls Owner Key
  • Microsoft owns keys in KEK and db
  • On ARM UEFI can’t be disabled
  • The user must be able to replace all the keys
  • Private key doesn’t need to be included in the code for GPL requirements
  • First boot Linux needs to be signed by Microsoft to stop users getting confused when installing Linux
  • To get Windows approval
    • Can’t malware Windows
    • Has to follow all windows 8 logo mandates
  • To be effective must carry the root of trust through the secure boot, to OS environment
    • eg, kernel modules must be signed and checked
  • Redhat / Canonical has Secure Boot
  • Develop a set of tools to enable the owner to easily control keys -Every kernel update will require the kernel hash/key be added to the table.

Red Hat

  • SHIM
  • module signing
  • boots a signed second stage loader
  • Hashs or keys
  • Only works with grub / efiboot - legacy link loaders
  • Only shim can access the keys
  • SHIM is only a link loader
  • SHIM doesn’t work on the current hardware due to a change with ACCESS_DENIED error

New Arch for Secure Boot

  • not mandated by MS
  • redesigned pre-loader
  • same as SHIM
  • no SSL, cut down size
  • uses hashes
  • GummiBoot now works
  • has a keytool
  • Doesn’t require a secret key