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.
-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) are all using this system to enable their boot loaders to run. Unfortunately, using a third-party signing service is an awkward solution for open source software. In fact, for this very reason two separate programs exist that shift the Secure Boot "train" from Microsoft's proprietary "track" to one that's more friendly to open source authors. Both of these programs (Shim and PreLoader) are available in binary form signed by Microsoft's key. Shim enables the computer to launch binaries that are signed by a key that's built into it or that the user adds to a list known as the Machine Owner Key (MOK) list. PreLoader enables the computer to launch binaries that the user has explicitly identified as being OK. Distributions beginning with Ubuntu 12.10 (and 12.04.2), Fedora 18, and OpenSUSE 12.3 use Shim, although the Ubuntu initially shipped with an early version of Shim that's useless for launching rEFInd. (Current versions of Ubuntu ship with more flexible versions of Shim.) PreLoader is used by some smaller and more specialized distributions, such as Arch Linux. You can switch from one to the other if you like, no matter what your distribution uses by default.
-There are three ways to sign a binary that will get it launched on a computer that uses Shim:
--
-
- Your boot loaders and kernels—Your OS boot loaders, and perhaps your Linux kernels, must be signed. They can be signed with any of the three key types. Indeed, your system may have a mix of all three types—a Windows 8 boot loader will most likely be signed with Microsoft's Secure Boot key, GRUB and kernels provided by most distributions will be signed with their own shim keys, and if you use your own locally-compiled kernel or a boot loader from an unusual source you may need to sign it with a MOK. Aside from signing, these files can be installed in exactly the same way as if your computer were not using Secure Boot. +
- Secure Boot keys—These keys are managed by the EFI + firmware. In a default configuration, Microsoft is the only party + that's more-or-less guaranteed to be able to sign boot loaders with + these keys; however, it's possible to replace + Microsoft's keys with your own, in order to take full control of + Secure Boot on your computer. The trouble is that this process is + tedious and varies in details from one computer to another. It's worth + noting that many, but not all, computers ship with Canonical's key, + which can help slightly when booting Ubuntu; if your computer is so + equipped, you can use any Shim you like and not worry about adding + Canonical's key to your MOK list, although you must still add a MOK key + for rEFInd itself. + +
- Shim's built-in keys—It's possible, but not necessary, to + compile Shim with a built-in public key. Its private counterpart can + then be used to sign binaries. In practice, this key type is limited in + utility; it's likely to be used by distribution maintainers to sign + their own version of GRUB and the Linux kernels that it launches, + nothing more. On the plus side, Shim's keys require little or no + maintenance by users. One potential complication is that if you swap + out one Shim binary for another, its built-in key may change, which + means that the replacement Shim might no longer launch its follow-on + boot loader or kernels linked to the first Shim. + +
- MOKs—Versions 0.2 and later of Shim support MOKs, which + give you the ability to add your own keys to the computer. If you want + to install multiple Linux distributions in Secure Boot mode, MOKs are + likely to be helpful. They're vital if you want to launch kernels you + compile yourself or use boot managers or boot loaders other than those + provided by your distribution.
Because of variables such as which version of shim you're using and whether you're installing a pre-signed version of rEFInd or want to sign it yourself, I can't provide an absolutely complete procedure for installing rEFInd to work with Secure Boot. Broadly speaking, though, the procedure should be something like this:
+All three key types are the same in form—Shim's built-in keys and MOKs are both generated using the same tools used to generate Secure Boot keys. The keys can be generated with the common openssl program, but signing EFI binaries requires either of two rarer programs: sbsign or pesign. If you use Shim with a distribution that doesn't support Secure Boot, you'll need to either sign the kernels yourself, which can be a hassle, or launch the kernels by way of a boot loader that doesn't check for signatures, such as ELILO.
--
+
+
+
- Boot the computer. This can be a challenge in and of itself. You may need to use a Secure Boot–enabled Linux emergency disc, temporarily disable Secure Boot, or do the work from Windows. +
- Download rEFInd in binary form (the binary zip or CD-R image file). If you download the binary zip file, unzip it; if you get the CD-R image file, burn it to a CD-R and mount it. +
- Download shim from Matthew J. Garrett's download site or from your distribution. (Don't use Ubuntu 12.10's version, though; as noted earlier, it's inadequate for use with rEFInd.) + +
- Copy the shim.efi and MokManager.efi binaries to the directory you intend to use for rEFInd—for instance, EFI/refind on the ESP. +
- Follow the installation instructions for rEFInd on the Installing rEFInd page; however, give rEFInd the filename grubx64.efi and register shim.efi with the EFI by using efibootmgr in Linux or bcdedit in Windows. This is most cleanly done by following the manual instructions; however, you can use the install.sh script if you subsequently rename the files and register shim.efi with efibootmgr. Be sure that rEFInd (as grubx64.efi), shim.efi, and MokManager.efi all reside in the same directory. +
- Shim—You can use any version of Shim you like. In many cases, one will already be installed on your computer from your distribution, called shim.efi or shimx64.efi in the distribution's directory on the ESP. If so, it's probably best to use that version, since its built-in key will handle your distribution's kernels. If you don't currently have a Shim installed, you can copy one from another computer, copy the file from a distribution installation disc, or download a version of Shim 0.2 (old, but still usable) signed with Microsoft's Secure Boot key here. 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 MokManager.efi program that also ships with the program. No matter what version of Shim you use, you must enroll rEFInd's MOK. Ubuntu 12.10 and 13.04 ship with an earlier version of Shim (0.1) that doesn't support MOKs; avoid Shim 0.1 for use with rEFInd. You should install Shim just as you would install other EFI boot loaders, as described here. For use in launching rEFInd, it makes sense to install shim.efi in EFI/refind on your ESP, although of course this detail is up to you. -
- Copy the refind.cer file from the rEFInd package to your ESP, ideally to a location with few other files. (The rEFInd installation directory should work fine.) +
- MokManager—This program is included with Shim 0.2 and later. It presents a user interface for managing MOKs, and it's launched by Shim if Shim can't find its default boot loader (generally grubx64.efi) or if that program isn't properly signed. In principle, this program could be signed with a Secure Boot key or a MOK, but such binaries are usually signed by Shim keys. This program should reside in the same directory as shim.efi, under the name MokManager.efi. 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. -
- Reboot. With any luck, you'll see a simple text-mode user interface with a label of Shim UEFI key management. This is the MokManager program, which shim launched when rEFInd failed verification because its key is not yet enrolled. +
- rEFInd—Naturally, you need rEFInd. Because Shim is hard-coded to launch a program called grubx64.efi, you must install rEFInd using that name and to the same directory in which shim.efi resides. In theory, rEFInd could be signed with a Secure Boot key, a Shim key, or a MOK; however, because Microsoft won't sign binaries distributed under the GPLv3, I can't distribute a version of rEFInd signed with Microsoft's Secure Boot key; and as I don't have access to the private Shim keys used by any distribution, I can't distribute a rEFInd binary signed by them. (If distributions begin including rEFInd in their package sets, though, such distribution-provided binaries could be signed with the distributions' Shim keys.) Thus, rEFInd will normally be signed by a MOK. Beginning with version 0.5.0, rEFInd binaries that I provide are signed by me. Beginning with version 0.5.1, the installation script provides an option to sign the rEFInd binary with your own key, provided the necessary support software is installed. -
- Press your down arrow key and press Enter to select Enroll key from disk. The screen will clear and prompt you to select a key, as shown here: +
- Your boot loaders and kernels—Your OS boot loaders, and perhaps your Linux kernels, must be signed. They can be signed with any of the three key types. Indeed, your system may have a mix of all three types—a Windows 8 boot loader will most likely be signed with Microsoft's Secure Boot key, GRUB and kernels provided by most distributions will be signed with their own Shim keys, and if you use your own locally-compiled kernel or a boot loader from an unusual source you may need to sign it with a MOK. Aside from signing, these files can be installed in exactly the same way as if your computer were not using Secure Boot. -
- 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 refind.cer file you copied to the ESP earlier. +
- Select refind.cer. You can type 1 to view the certificate's details if you like, or skip that and type 0 to enroll the key. +
- Back out of any directories you entered and return to the MokManager main menu. +
- Boot the computer. This can be a challenge in and of itself. You may + need to use a Secure Boot–enabled Linux emergency disc, + temporarily disable Secure Boot, or do the work from Windows. + +
- Download rEFInd in binary form (the binary + zip or CD-R image file). If you download the binary zip file, unzip it; + if you get the CD-R image file, burn it to a CD-R and mount it. + +
- Download Shim from Matthew J. Garrett's + download site or from your distribution. (Don't use an early 0.1 + version, though; as noted earlier, it's inadequate for use with + rEFInd.) + + + +
- Copy the shim.efi and MokManager.efi binaries to the + directory you intend to use for rEFInd—for instance, + EFI/refind on the ESP. + +
- Follow the installation instructions for rEFInd on the Installing rEFInd page; however, you should + normally give rEFInd the filename grubx64.efi and register + shim.efi with the EFI by using efibootmgr in Linux or + bcdedit in Windows. Be sure that rEFInd (as + grubx64.efi), shim.efi, and MokManager.efi + all reside in the same directory. If you're using Shim 0.7 or later and + installing it under Linux, you may optionally keep rEFInd's + refind_x64.efi name; but you must then tell Shim to use rEFInd + by passing an additional -u "shim.efi refind_x64.efi" option + to efibootmgr. Change the filenames to the actual filenames + used by Shim and rEFInd, respectively. + +
- Copy the refind.cer file from the rEFInd package to your ESP, + ideally to a location with few other files. (The rEFInd installation + directory should work fine.) + +
- Reboot. With any luck, you'll see a simple text-mode user interface + with a label of Shim UEFI key management. This is the + MokManager program, which Shim launched when rEFInd failed verification + because its key is not yet enrolled. + +
- Press your down arrow key and press Enter to select Enroll key from
+ disk. The screen will clear and prompt you to select a key, as
+ shown here:
+
+
+ + This user interface was used in early versions of MokManager, but + somewhere between versions 0.4 and 0.7, the user interface received an + upgrade. If you've got a more recent version, it will look more like + this: + +
+
+ - 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 refind.cer file + you copied to the ESP earlier. (Note that in the early user interface + 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!) + +
- Select refind.cer. You can type 1 + to view the certificate's details if you like, or skip that and type + 0 to enroll the key. + +
- Back out of any directories you entered and return to the MokManager + main menu.
- Select Continue boot at the main menu.
- If it's not already installed, install OpenSSL on your computer. (It normally comes in a package called openssl. +
- If it's not already installed, install OpenSSL on your computer. (It + normally comes in a package called openssl.) -
- Type the following two commands to generate your public and private keys: +
- If you did not re-sign your rEFInd binaries with
+ refind-install's --localkeys option, type the
+ following two commands to generate your public and private keys:
-$ openssl req -new -x509 -newkey rsa:2048 -keyout MOK.key -out MOK.crt \ - -nodes -days 3650 -subj "/CN=Your Name/" -$ openssl x509 -in MOK.crt -out MOK.cer -outform DER +$ openssl req -new -x509 -newkey rsa:2048 -keyout refind_local.key \ + -out refind_local.crt -nodes -days 3650 -subj "/CN=Your Name/" +$ openssl x509 -in refind_local.crt -out refind_local.cer -outform DER
-Change Your Name to your own name or other identifying characteristics, and adjust the certificate's time span (set via -days) as you see fit. If you omit the -nodes option, the program will prompt you for a passphrase for added security. Remember this, since you'll need it to sign your binaries. The result is a private key file (MOK.key), which is highly sensitive since it's required to sign binaries, and two public keys (MOK.crt and MOK.cer), which can be used to verify signed binaries' authenticity. The two public key files are equivalent, but are used by different tools—sbsigntool uses MOK.crt to sign binaries, but MokManager uses MOK.cer to enroll the key.
+ Change Your Name to your own name or other identifying
+ characteristics, and adjust the certificate's time span (set via
+ -days) as you see fit. If you omit the -nodes option,
+ the program will prompt you for a passphrase for added security.
+ Remember this, since you'll need it to sign your binaries. The result
+ is a private key file (refind_local.key), which is highly
+ sensitive since it's required to sign binaries, and two public keys
+ (refind_local.crt and refind_local.cer), which can be
+ used to verify signed binaries' authenticity. The two public key files
+ are equivalent, but are used by different
+ tools—sbsigntool uses refind_local.crt to sign
+ binaries, but MokManager uses refind_local.cer to enroll the
+ key. If you used refind-install's --localkeys option,
+ this step is unnecessary, since these keys have already been created
+ and are stored in /etc/refind.d/keys/.
+
+ - Copy the three key files to a secure location and adjust permissions + such that only you can read refind_local.key. You'll need + these keys to sign future binaries, so don't discard them. + +
- Copy the refind_local.cer file to your ESP, ideally to a + location with few other files. (MokManager's user interface becomes + unreliable when browsing directories with lots of files.) + +
- Download and install the sbsigntool package. Binary links for + various distributions are available from the OpenSUSE + Build Service, or you can obtain the source code by typing git clone + git://kernel.ubuntu.com/jk/sbsigntool. + +
- Sign your binary by typing sbsign --key + refind_local.key --cert refind_local.crt --output binary-signed.efi binary.efi, adjusting the + paths to the keys and the binary names. + +
- Copy your signed binary to a suitable location on the ESP for rEFInd to + locate it. Be sure to include any support files that it needs, + too. + +
- Check your refind.conf file to ensure that the + showtools option is either commented out or includes + mok_tool among its options. + +
- Reboot. You can try launching the boot loader you just installed, but + chances are it will generate an Access Denied message. For it + to work, you must launch MokManager using the tool that rEFInd presents + on its second row. You can then enroll your refind_local.cer + key just as you enrolled the refind.cer key. -
- Copy the three key files to a secure location and adjust permissions such that only you can read MOK.key. You'll need these keys to sign future binaries, so don't discard them. - -
- Copy the MOK.cer file to your ESP, ideally to a location with few other files. (MokManager's user interface becomes unreliable when browsing directories with lots of files.) +
- Download and install the sbsigntool package. Binary links for various distributions are available from the OpenSUSE Build Service, or you can obtain the source code by typing git clone git://kernel.ubuntu.com/jk/sbsigntool. +
- Sign your binary by typing sbsign --key MOK.key --cert MOK.crt --output binary-signed.efi binary.efi, adjusting the paths to the keys and the binary names. + +
- Copy your signed binary to a suitable location on the ESP for rEFInd to locate it. Be sure to include any support files that it needs, too. +
- Check your refind.conf file to ensure that the showtools option is either commented out or includes mok_tool among its options. +
- Reboot. You can try launching the boot loader you just installed, but chances are it will generate an Access Denied message. For it to work, you must launch MokManager using the tool that rEFInd presents on its second row. You can then enroll your MOK.cer key just as you enrolled the refind.cer key. +
- Boot the computer. As with Shim, this can be a challenge; you may need + to boot with Secure Boot disabled, use a Secure Boot–enabled live + CD, or do the installation from Windows. + +
- Download rEFInd in binary form (the binary + zip or CD-R image file). If you download the binary zip file, unzip it; + if you get the CD-R image file, burn it to a CD-R and mount it. + +
- Download PreLoader from its + release page or by clicking the following links. Be sure to get + both the PreLoader.efi + and HashTool.efi + files. + +
- Copy the PreLoader.efi and HashTool.efi binaries to + the directory you intend to use for rEFInd—for instance, + EFI/refind on the ESP. + +
- Follow the installation instructions for rEFInd on the Installing rEFInd page; however, give rEFInd + the filename loader.efi and register PreLoader.efi + with the EFI by using efibootmgr in Linux or bcdedit + in Windows. Be sure that rEFInd (as loader.efi), + PreLoader.efi, and HashTool.efi all reside in the + same directory. + +
- Reboot. With any luck, you'll see HashTool appear with a warning + message stating that it was unable to launch loader.efi and + declaring that it will launch HashTool.efi. Press the Enter + key to continue. + +
- HashTool should now appear. It should give you three or four options, + including Enroll Hash, as shown here. Select this option + +
- You can now select the binary you want to authorize. You should first + select loader.efi, since that's rEFInd. The program presents + the hash (a very long number) and asks for confirmation. Be sure to + select Yes. + +
- Repeat the preceding two steps for any additional binaries you might + want to enroll. These include any EFI filesystem drivers you're using, + any boot loaders you're launching from rEFInd (other than those that + are already signed, such as Microsoft's boot loader), and possibly your + Linux kernel. + +
- At the HashTool main menu, select Exit. rEFInd should + launch.
- rEFInd can launch one shim/MOK-signed driver, no more. If you - try to launch two drivers, rEFInd throws up an Access Denied - error for the second driver. - -
- ELILO can't find its configuration file when launched from rEFInd in - Secure Boot mode. The same may be true of GRUB Legacy or other boot loaders, - but I haven't tested them. (GRUB 2 seems fine.) - -
- Signing the Windows boot loader with a MOK won't work; it hangs, probably - for reasons similar to the ones that cause ELILO to fail. 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, though. +
- rEFInd uses the same EFI "hooks" as PreLoader. This method, however, is + part of an optional EFI subsystem, so in theory some EFIs might not + support it. For months, I knew of no such implementation, but this + SuperUser question indicates that at least one such implementation + exists. Subsequent discussions on the site imply that the computer + doesn't support Secure Boot at all. The bottom line: If you encounter + the error message Failed to install override security policy, + try removing PreLoader from your boot path.
- Under certain circumstances, the time required to launch a boot loader can increase. This is unlikely to be noticeable for the average small @@ -243,19 +504,34 @@ Change Your Name to your own name or other identifying characteristics, filesystems, such as Linux kernels on ext2fs, ext3fs, or ReiserFS partitions. -
- Secure Boot mode doesn't work on x86 (IA32) or ARM systems, just - on x86-64 (AMD64) computers. This is largely because shim has - the same limitations. +
- rEFInd's own Secure Boot support is theoretically able to work on + non-x86-64 platforms; however, to the best of my knowledge, Shim + and PreLoader both work only on x86-64, and rEFInd is dependent + upon these tools. In principle, you should be able to replace + your computer's standard Secure Boot keys to use Secure Boot on + these platforms with rEFInd, but this approach will require either + built-in key-modification tools in the computer's setup utility or a + build of LockDown.efi for your platform. I've not tested this + approach on x86 or ARM, so I can't say whether it would actually + work. + +
- 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.
PreLoader is easier to set up on a distribution that doesn't support Shim because PreLoader doesn't rely on keys; instead, you tell it which binaries you trust and it will let you launch them. This works well on a system with boot managers, boot loaders, and kernels that seldom change. It's not a good solution for distribution maintainers, though, because it requires that users manually add binaries to PreLoader's list of approved binaries when the OS is installed and every time those binaries change. Also, PreLoader relies on a helper program, HashTool, to enroll hashes. (This is Geek for "tell the computer that a binary is OK.") Unfortunately, the initial (and, as far as I know, only signed) HashTool can enroll hashes only from the partition from which it was launched, so if you want to use rEFInd to launch Linux kernels directly, it's easiest if you mount your EFI System Partition (ESP) at /boot in Linux or copy your kernels to the ESP. Another approach is to copy HashTool.efi to the partition that holds your kernel and rename it to almost anything else. rEFInd will then treat it like an OS boot loader and create a menu entry for it, enabling you to launch it as needed.
-Beginning with version 0.5.0, rEFInd can communicate with the Shim system to authenticate boot loaders. If a boot loader has been signed by a valid UEFI Secure Boot key, a valid Shim key, or a valid MOK, rEFInd will launch it. rEFInd will also launch unsigned boot loaders or those with invalid signatures if Secure Boot is disabled in or unsupported by the firmware. (If that's your situation, you needn't bother reading this page.) PreLoader is designed in such a way that it requires no explicit support in rEFInd to work.
+ +My binary builds of rEFInd version 0.5.0 and later ship signed with my own keys, and I provide the public version of this key with the rEFInd package. This can help simplify setup, since you needn't generate your own keys to get rEFInd working. The rEFInd PPA for Ubuntu ships unsigned binaries, but the installation script that runs automatically when the package is installed signs the binaries with a local key as it installs them. In either case, if you lack public keys for the boot loaders that rEFInd launches, you'll need to sign your boot loaders, as described in the Managing Your MOKs section.
+ + +Using rEFInd with Shim
+ -Because several major distributions support Shim, I describe it first. You may need to adjust the rEFInd installation process to get it working with Shim, especially if you're not using a distribution that uses this software. In addition to installing Shim, you should know how to manage your MOKs, so I describe this topic, too. If you don't want to use Shim, you can skip ahead to the section on PreLoader.
-Installing Shim and rEFInd
+ + + + +A working Secure Boot installation of rEFInd involves at least three programs, and probably four or more, each of which must be installed in a specific way:
--
-
+
If you've installed a distribution that provides Shim and can boot it with Secure Boot active, and if you then install rEFInd using the RPM file that I provide or by running refind-install, chances are you'll end up with a working rEFInd that will start up the first time, with one caveat: You'll have to use MokManager to add rEFInd's MOK to your MOK list, as described shortly. If you don't already have a working copy of Shim on your ESP, your task is more complex. Broadly speaking, the procedure should be something like this:
--
-
At this point the computer may boot into its default OS, reboot, or perhaps even hang. When you reboot it, though, rEFInd should start up in Secure Boot mode. (You can verify this by selecting the About rEFInd tool in the main menu. Check the Platform item in the resulting screen; it should verify that Secure Boot is active.) You should now be able to launch any boot loader signed with a key recognized by the firmware or by shim (including any MOKs you've enrolled). If you want to manage keys in the future, rEFInd displays a new icon in the second (tools) row you can use to launch MokManager. (This icon appears by default if MokManager is installed, but if you edit showtools in refind.conf, you must be sure to include mok_tool as an option in order to gain access to it.)
+At this point the computer may boot into its default OS, reboot, or perhaps even hang. When you reboot it, though, rEFInd should start up in Secure Boot mode. (You can verify this by selecting the About rEFInd tool in the main menu. Check the Platform item in the resulting screen; it should verify that Secure Boot is active.) You should now be able to launch any boot loader signed with a key recognized by the firmware or by Shim (including any MOKs you've enrolled). If you want to manage keys in the future, rEFInd displays a new icon in the second (tools) row you can use to launch MokManager. (This icon appears by default if MokManager is installed, but if you edit showtools in refind.conf, you must be sure to include mok_tool as an option in order to gain access to it.)
-If you're using Ubuntu 12.10, you can't use its version of shim, but you can replace it with Garrett's shim. The problem is that Ubuntu's GRUB and kernel will then be signed by an unknown key. Unfortunately, I haven't found a suitable public key file on Ubuntu's distribution medium, so you may need to sign GRUB and/or your kernels with your own MOK. In principle, you should be able to use shim 0.2 or later from future distributions that include it; but you must be sure that whatever you use supports MokManager.
+If you're using rEFInd to boot multiple Linux versions, chances are you'll need to add the keys for the distributions whose Shim you're not using as MOKs. rEFInd ships with a selection of such keys and copies them to the keys subdirectory of the rEFInd installation directory on the ESP as a convenience. Note that you must enroll keys with .cer or .der filename extensions. Although .crt files contain the same information, their format is different and they cannot be used by MokManager.
-Managing Your MOKs
+Managing Your MOKs
-The preceding instructions provided the basics of getting rEFInd up and running, including using MokManager to enroll a MOK on your computer. If you need to sign binaries, though, you'll have to use additional tools. The OpenSSL package provides the cryptographic tools necessary, but actually signing EFI binaries requires additional software. Two packages for this are available: sbsigntool and pesign. Both are available in binary form from this OpenSUSE Build Service (OBS) repository. The following procedure uses sbsigntool. To sign your own binaries, follow these steps:
+The preceding instructions provided the basics of getting rEFInd up and running, including using MokManager to enroll a MOK on your computer. If you need to sign binaries, though, you'll have to use additional tools. The OpenSSL package provides the cryptographic tools necessary, but actually signing EFI binaries requires additional software. Two packages for this are available: sbsigntool and pesign. Both are available in binary form from this OpenSUSE Build Service (OBS) repository, and many distributions ship with at least one of them. The following procedure uses sbsigntool. To sign your own binaries, follow these steps (you can skip the first five steps if you've successfully used refind-install's --localkeys option):
-
-
At this point you should be able to launch the binaries you've signed. Unfortunately, there can still be problems; see the upcoming section, Secure Boot Caveats, for information on them. Alternatively, you can try using PreLoader rather than Shim.
-Using rEFInd with PreLoader
+ -If you want to use Secure Boot with a distribution that doesn't come with Shim but the preceding description exhausts you, take heart: PreLoader is easier to set up and use for your situation! Unfortunately, it's still not as easy to use as not using Secure Boot at all, and it's got some drawbacks, but it may represent an acceptable middle ground. To get started, proceed as follows:
--
-
+ +
+ + + +
At this point you should be able to launch the binaries you've signed. Unfortunately, there can still be problems at this point....
+If you did everything right, rEFInd should now launch follow-on boot loaders and kernels, including both programs signed with the platform's Secure Boot keys and binaries that you've authorized with HashTool. If you need to authorize additional programs, you can do so from rEFInd by using the MOK utility tool icon that launches HashTool.efi from the second row of icons. (This icon should appear by default, but if you uncomment the showtools token in refind.conf, be sure that mok_tool is present among the options.)
+ +Although PreLoader is easier to set up than Shim, particularly if you need to launch programs or kernels that aren't already signed, it suffers from the problem that you must register every new program you install, including Linux kernels if you launch them directly from rEFInd. This need can be a hassle if you update your kernels frequently, and every new registration chews up a little space in your NVRAM. Nonetheless, PreLoader can be a good Secure Boot solution for many users or if you want to build a portable Linux installation that you can use on any computer with minimal fuss.
Secure Boot Caveats
-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:
+rEFInd's Secure Boot originated with version 0.5.0 of the program, and was revamped for version 0.6.2, both released in late 2012. It's worked well for myself and several others with whom I've corresponded; but you might still run into problems. Some issues you might encounter include the following:
-
-
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 gummiboot 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. (You can launch gummiboot from PreLoader and it should work, though, because of technical differences between how Shim and PreLoader work.)
+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.)
-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.
+Some of the awkwardness of using rEFInd with Secure Boot is due to the need to manage MOKs (either keys with Shim or hashes with PreLoader). Such problems would evaporate if you could get a copy of rEFInd signed with your distribution's Secure Boot key. Thus, if you're annoyed by such problems, try filing a feature request with your distribution maintainer to have them include rEFInd (and sign it!) with their official package set.
-
copyright © 2012 by Roderick W. Smith
+copyright © 2012–2015 by Roderick W. Smith
This document is licensed under the terms of the GNU Free Documentation License (FDL), version 1.3.