href="mailto:rodsmith@rodsbooks.com">rodsmith@rodsbooks.com</a></p>
<p>Originally written: 11/13/2012; last Web page update:
-12/21/2012, referencing rEFInd 0.6.1</p>
+1/26/2013, referencing rEFInd 0.6.6</p>
<p>I'm a technical writer and consultant specializing in Linux technologies. This Web page is provided free of charge and with no annoying outside ads; however, I did take time to prepare it, and Web hosting does cost money. If you find this Web page useful, please consider making a small donation to help keep this site up and running. Thanks!</p>
<p class="sidebar"><b>Note:</b> My <a href="http://www.rodsbooks.com/efi-bootloaders/">Managing EFI Boot Loaders for Linux</a> Web page includes a much more detailed description of Secure Boot in its <a href="http://www.rodsbooks.com/efi-bootloaders/secureboot.html">Dealing with Secure Boot</a> sub-page. You should consult this page if you want to disable Secure Boot, generate your own keys, or perform other such tasks.</p>
+<div class="navbar">
+
+<h4 class="tight">Contents</h4>
+
+<ul>
+
+<li class="tight"><a href="#basic">Basic Issues</li>
+
+<li class="tight"><a href="#installation">Installation Issues</a></li>
+
+<li class="tight"><a href="#mok">Managing Your MOKs</a></li>
+
+<li class="tight"><a href="#caveats">Secure Boot Caveats</a></li>
+
+</ul>
+
+</div>
+
<p>If you're using a computer that supports Secure Boot, you may run into extra complications. This feature is intended to make it difficult for malware to insert itself early into the computer's boot process. Unfortunately, it also complicates multi-boot configurations such as those that rEFInd is intended to manage. This page describes some <a href="#basic">secure boot basics</a> and two specific aspects of rEFInd and its interactions with Secure Boot: <a href="#installation">installation issues</a> and <a href="#mok">MOK management.</a> It concludes with a look at <a href="#caveats">known bugs and limitations</a> in rEFInd's Secure Boot features.</p>
<a name="basic">
<p>Through 2012, it became obvious that Secure Boot would be a feature that was controlled, to a large extent, by Microsoft. This is because Microsoft requires that non-server computers that display Windows 8 logos ship with Secure Boot enabled. As a practical matter, this also means that such computers ship with Microsoft's keys in their firmware. In the absence of an industry-standard body to manage the signing of Secure Boot keys, this means that Microsoft's key is the only one that's more-or-less guaranteed to be installed on the computer, thus blocking the ability to boot any OS that lacks a boot path through Microsoft's signing key.</p>
-<p>Fortunately, Microsoft will sign third-party binaries with their key
. A payment of $99 to Verisign enables a software distributor to sign as many binaries as desired. Red Hat (Fedora), Novell (SUSE), and Canonical (Ubuntu) have all announced plans to take advantage of this system. Unfortunately, using a third-party signing service is an awkward solution for open source software. In fact, for this very reason Red Hat has developed a program that it calls <i>shim</i> that essentially shifts the Secure Boot "train" from Microsoft's proprietary "track" to one that's more friendly to open source authors. Shim is signed by Microsoft and redirects the boot process to another boot loader that can be signed with keys that the distribution maintains and that are built into shim. Fedora 18 is expected to use this system. SUSE has announced that it will use the same system, as does Ubuntu with version 12.10 and later. SUSE has contributed to the shim approach by providing expansions to shim that support a set of keys that users can maintain themselves. These keys are known as Machine Owner Keys (MOKs), and managing them is described later, in <a href="#mok">Managing MOKs.</a> To reiterate, then, there are potentially three ways to sign a binary that will get it launched on a computer that uses shim:</p>
+<p>Fortunately, Microsoft will sign third-party binaries with their key
—or more precisely, with a key that Microsoft uses to sign third-party binaries. (Microsoft uses another key to sign its own binaries, and some devices, such as the Microsoft Surface tablet, lack the third-party Microsoft key.) A payment of $99 to Verisign enables a software distributor to sign as many binaries as desired. Red Hat (Fedora), Novell (SUSE), and Canonical (Ubuntu) have all announced plans to take advantage of this system. Unfortunately, using a third-party signing service is an awkward solution for open source software. In fact, for this very reason Red Hat has developed a program that it calls <i>shim</i> that essentially shifts the Secure Boot "train" from Microsoft's proprietary "track" to one that's more friendly to open source authors. Shim is signed by Microsoft and redirects the boot process to another boot loader that can be signed with keys that the distribution maintains and that are built into shim. Fedora 18 also uses this system. SUSE has announced that it will use the same system, as does Ubuntu with version 12.10 and later. SUSE has contributed to the shim approach by providing expansions to shim that support a set of keys that users can maintain themselves. These keys are known as Machine Owner Keys (MOKs), and managing them is described later, in <a href="#mok">Managing MOKs.</a> To reiterate, then, there are potentially three ways to sign a binary that will get it launched on a computer that uses shim:</p>
<ul>
<ul>
-<li><b>shim</b>—You can download a version of shim signed with Microsoft's Secure Boot key <a href="http://www.codon.org.uk/~mjg59/shim-signed/">here.</a> This version (created by shim's developer, former Red Hat employee Matthew J. Garrett) includes a shim key that's used by nothing but the <tt>MokManager.efi</tt> program that also ships with the program. Thus, to use this version of shim, you must use MOKs.
Ubuntu 12.10 ships with its own shim, but that version doesn't support MOKs and so is useless for launching rEFInd. Future versions of Fedora, SUSE, and probably other distributions will come with their own variants of shim, most of which will no doubt support their own shim keys as well as MOKs. You should install shim just as you would install other EFI boot loaders, as described <a href="http://www.rodsbooks.com/efi-bootloaders/installation.html">here.</a> For use in launching rEFInd, it makes sense to install <tt>shim.efi</tt> in <tt>EFI/refind</tt> on your ESP, although of course this detail is up to you.</li>
+<li><b>shim</b>—You can download a version of shim signed with Microsoft's Secure Boot key <a href="http://www.codon.org.uk/~mjg59/shim-signed/">here.</a> This version (created by shim's developer, former Red Hat employee Matthew J. Garrett) includes a shim key that's used by nothing but the <tt>MokManager.efi</tt> program that also ships with the program. Thus, to use this version of shim, you must use MOKs.
Fedora 18's version of shim includes its own key but can also use MOKs; but to use it with rEFInd, you must still enroll rEFInd's MOK. Ubuntu 12.10 ships with its own shim, but that version doesn't support MOKs and so is useless for launching rEFInd. Future versions of SUSE and probably other distributions will come with their own variants of shim, most of which will no doubt support their own shim keys as well as MOKs. You should install shim just as you would install other EFI boot loaders, as described <a href="http://www.rodsbooks.com/efi-bootloaders/installation.html">here.</a> For use in launching rEFInd, it makes sense to install <tt>shim.efi</tt> in <tt>EFI/refind</tt> on your ESP, although of course this detail is up to you.</li>
<li><b>MokManager</b>—This program is included with shim 0.2 and later. It presents a crude user interface for managing MOKs, and it's launched by shim if shim can't find its default boot loader (generally <tt>grubx64.efi</tt>) or if that program isn't properly signed. In principle, this program could be signed with a Secure Boot key or a MOK, but the binary in Garrett's shim 0.2 is signed with a shim key, and I expect that versions distributed with most Linux distributions will also be signed by their respective shim keys. This program should reside in the same directory as <tt>shim.efi</tt>, under the name <tt>MokManager.efi</tt>. Although you could theoretically do without MokManager, in practice you'll need it at least temporarily to install the MOK with which rEFInd is signed.</li>
href="http://www.codon.org.uk/~mjg59/shim-signed/">Matthew J. Garrett's
download site</a> or from your distribution. (Don't use Ubuntu 12.10's
version, though; as noted earlier, it's inadequate for use with
- rEFInd.)</li>
+ rEFInd.) Fedora 18 ships with a signed shim, but I've not yet tested
+ it.</li>
<p class="sidebar"><b>Tip:</b> If you're running Linux, you can save some effort by using the <tt>install.sh</tt> script with its <tt>--shim <tt class="variable">/path/to/shim.efi</tt></tt> option rather than installing manually, as in steps 4–6 of this procedure. If you've installed <tt>openssl</tt> and <tt>sbsign</tt>, using <tt>--localkeys</tt> will generate local signing keys and re-sign the rEFInd binaries with your own key, too. You can then use <tt>sbsign</tt> and the keys in <tt>/etc/refind.d/keys</tt> to sign your kernels or boot loaders.</p>
<li>Each of the lines with a long awkward string represents a disk
partition. Select one and you'll see a list of files. Continue
selecting subdirectories until you find the <tt>refind.cer</tt> file
- you copied to the ESP earlier.</li>
+ you copied to the ESP earlier. (Note that the long lines can wrap
+ and hide valid entries on the next line, so you may need to select
+ a disk whose entry is masked by another one!)</li>
<li>Select <tt>refind.cer</tt>. You can type <tt class="userinput">1</tt>
to view the certificate's details if you like, or skip that and type
<h2>Secure Boot Caveats</h2>
</a>
-<p>rEFInd's Secure Boot support is brand-new with version 0.5.0 of the program. Unfortunately, rEFInd, like shim, must essentially bypass UEFI security features, and must simultaneously not create security problems, in order to work. Unfortunately, the procedures that rEFInd uses to do this (which were lifted straight from shim) play "fast and loose" with the UEFI rules. This fact creates a number of limitations, which include (but are almost certainly not limited to) the following:</p>
+<p>rEFInd's Secure Boot support is brand-new with version 0.5.0 of the program, and was revamped for version 0.6.2. I believe rEFInd 0.6.2's Secure Boot support to be significantly superior to that of previous versions, but you might still run into problems. Some issues you might encounter include the following:</p>
<ul>
-<li>rEFInd can launch <i>one</i> shim/MOK-signed driver, no more. If you
- try to launch two drivers, rEFInd throws up an <tt>Access Denied</tt>
- error for the second driver.</li>
-
-<li>Signing the Windows boot loader with a MOK won't work; it hangs.
- Fortunately, the Windows 8 boot loader should work because it should be
- verified and launched via EFI calls rather than via the new
- shim-derived code. (I lack a Windows 8 installation for testing,
- though.) This limitation could affect you if you want to boot Windows 7
- with Secure Boot active.</li>
-
<li>Under certain circumstances, the time required to launch a boot loader
can increase. This is unlikely to be noticeable for the average small
boot loader, but could be significant for larger boot loaders on slow
filesystems, such as Linux kernels on ext2fs, ext3fs, or ReiserFS
partitions.</li>
-<li>Secure Boot mode doesn't work on <i>x</i>86 (IA32) or ARM systems, just
- on <i>x</i>86-64 (AMD64) computers. This is largely because shim has
- the same limitations.</li>
+<li>As of version 0.6.2, rEFInd's own Secure Boot support is theoretically
+ able to work on non-<i>x</i>86-64 platforms; however, shim 0.2 works
+ only on <i>x</i>86-64, and rEFInd is dependent upon shim. Thus, you'll
+ have to wait for future shim developments if you want to use Secure
+ Boot on <i>x</i>86 or ARM computers.</li>
+
+<li>I currently lack a Windows 8 installation with which to test, so I can't
+ even be 100% positive that rEFInd will launch Windows 8 in Secure Boot
+ ode. (It should, though, since it can launch other boot loaders that have
+ been signed with Microsoft's keys.) In theory, signing Microsoft's boot
+ loader with a MOK should work. This might be handy if you want to replace
+ your computer's built-in keys with your own but still boot Windows—but
+ be aware that if Windows replaces its boot loader, it will then stop
+ working.</li>
</ul>
-<p>My focus in testing rEFInd's Secure Boot capabilities has been on getting Linux kernels with EFI stub loaders to launch correctly. I've done some minimal testing with GRUB 2, though. I've also tested some self-signed binaries, such as an EFI shell and MokManager. (The EFI shell launches, but will not itself launch anything that's not been signed with a UEFI Secure Boot key. This of course limits its utility.)</p>
+<p>If you launch a boot loader or other program from rEFInd that relies on the EFI's standard program-launching code, that program should take advantage of shim and its MOKs. For instance, if you launch <a href="http://freedesktop.org/wiki/Software/gummiboot">gummiboot</a> from rEFInd (and rEFInd from shim), gummiboot should be able to launch shim/MOK-signed Linux kernels. This is not currently true if you launch gummiboot directly from shim.</p>
+
+<p>My focus in testing rEFInd's Secure Boot capabilities has been on getting Linux kernels with EFI stub loaders to launch correctly. I've done some minimal testing with GRUB 2, though. I've also tested some self-signed binaries, such as an EFI shell and MokManager. (The EFI shell launches, but will not itself launch anything that's not been signed with a UEFI Secure Boot key, even with rEFInd 0.6.2. This of course limits its utility.)</p>
-<p>At the moment, I consider rEFInd's shim/MOK support to be of alpha quality. I'm releasing it in this state in the hope of getting feedback from adventurous early adopters. I expect to improve the installation procedure, and with any luck fix some of the known bugs, in the next couple of versions. Some of the usability improvements are dependent upon MOK-capable versions of shim being released with major distributions; such versions of shim, with kernels signed with the key that matches the one built into shim, will greatly reduce the need for users to sign boot loaders.</p>
+<p>At the moment, I consider rEFInd's shim/MOK support to be of late alpha quality. I'm releasing it in this state in the hope of getting feedback from adventurous early adopters. Some of the usability improvements are dependent upon MOK-capable versions of shim being released with major distributions; such versions of shim, with kernels signed with the key that matches the one built into shim, will greatly reduce the need for users to sign boot loaders.</p>
<hr />
-<p>copyright © 2012 by Roderick W. Smith</p>
+<p>copyright © 2012–2013 by Roderick W. Smith</p>
<p>This document is licensed under the terms of the <a href="FDL-1.3.txt">GNU Free Documentation License (FDL), version 1.3.</a></p>