[Linux-aus] Fwd: [free-software-melb] Draft Fedora plan to cope with Secure Boot on x86 hardware

[Bianca Gibson]

Hi everyone,

Update on secure boot from the Melbourne Free Software mailing list.

---------- Forwarded message ----------
From: Chris Samuel <chris at csamuel.org>
Date: 31 May 2012 16:43
Subject: [free-software-melb] Draft Fedora plan to cope with Secure Boot on
x86 hardware
To: Melbourne Free Software Interest Group <
free-software-melb at lists.softwarefreedom.com.au>


Hi all,

Matthew Garrett has just posted a draft plan on how Fedora 18 plans to
cope with Windows 8 certified x86 hardware that has Secure Boot
enabled in EFI.

http://mjg59.dreamwidth.org/12368.html

Basically it involves signing up with Microsoft, paying a $99 one-off
fee and then getting them to sign a boot shim that will boot Grub2
that has been signed by a Fedora key.  Then it has to be signed code
all the way down to user space, so no loading out-of-tree drivers,
filesystems or other modules, either FLOSS or proprietary (and
certainly not a custom kernels) whilst Secure Boot is enabled.

For those who've not come across what this means, he has a nice
summary:

# Secure boot is built on the idea that all code that can touch the
# hardware directly is trusted, and any untrusted code must go through
# the trusted code. This can be circumvented if users can execute
# arbitrary code in the kernel. So, we'll be moving to requiring
# signed kernel modules and locking down certain aspects of kernel
# functionality. The most obvious example is that it won't be possible
# to access PCI regions directly from userspace, which means all
# graphics cards will need kernel drivers. Userspace modesetting will
# be a thing of the past. Again, disabling secure boot will disable
# these restrictions.
#
# Signed modules are obviously troubling from a user perspective.
# We'll be signing all the drivers that we ship, but what about out
# of tree drivers? We don't have a good answer for that yet. As
# before, we don't want any kind of solution that works for us
# but doesn't work for other distributions. Fedora-only or
# Ubuntu-only drivers are the last thing anyone wants, and this
# really needs to be handled in a cross-distribution way.


Interestingly he also shows that you can use Secure Boot to ensure
that your system will only be able to boot Fedora (etc) and never boot
a proprietary OS:

# A system in custom mode should allow you to delete all existing keys
# and replace them with your own. After that it's just a matter of
# re-signing the Fedora bootloader (like I said, we'll be providing
# tools and documentation for that) and you'll have a computer that
# will boot Fedora but which will refuse to boot any Microsoft code.
# It may be a little more awkward for desktops because you may have
# to handle the Microsoft-signed UEFI drivers on your graphics and
# network cards, but this is also solvable. I'm looking at ways to
# implement a tool to allow you to automatically whitelist the
# installed drivers. Barring firmware backdoors, it's possible to
# configure secure boot such that your computer will only run software
# you trust. Freedom means being allowed to run the software you want
# to run, but it also means being able to choose the software you
# don't want to run.


Interesting times!

cheers,
Chris
--
 Chris Samuel  :  http://www.csamuel.org/  :  Melbourne, VIC

This email may come with a PGP signature as a file. Do not panic.
For more info see: http://en.wikipedia.org/wiki/OpenPGP

_______________________________________________
Free-software-melb mailing list
Free-software-melb at lists.softwarefreedom.com.au
http://lists.softwarefreedom.com.au/mailman/listinfo/free-software-melb
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linux.org.au/pipermail/linux-aus/attachments/20120531/e9055c36/attachment.htm