Because shim and MOK are being supported by several of the major players in the Linux world, I've decided to do the same with rEFInd. 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 key, 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.)
-Version 0.5.0 doesn't yet ship in a pre-signed form; you'll need to create your own keys, as described shortly, and use them to sign your binary of rEFInd. I'm forcing you to do this because it's necessary to sign your post-rEFInd binaries anyhow.
+Version 0.5.0 ships 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; however, without public keys for the boot loaders that rEFInd launches, you'll still need to generate keys and sign your boot loaders, as described in the Managing Your MOKs section.
Installation Issues
@@ -128,69 +128,91 @@ href="mailto:rodsmith@rodsbooks.com">rodsmith@rodsbooks.com-
-
- shim—You can download a version of shim signed with Microsoft's Secure Boot key here. This version (created by shim's developer, Matthew J. Garrett) includes a shim key that's signed nothing but the MokManager.efi 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 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. +
- shim—You can download a version of shim 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. 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 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. -
- MokManager—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 grubx64.efi) or if that program isn't properly signed. In principle, this program could be signed with 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 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. +
- MokManager—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 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 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 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. -
- 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. Thus, rEFInd will normally be signed by a MOK. As of version 0.5.0, you must sign your rEFInd binary with your own MOK. +
- 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.
- 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.
Because of variables such as which version of shim you're using, 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:
+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:
- 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. + +
- 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: + +
- 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. + +
- Select Continue boot at the main menu. + +
+ +
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.
+ + +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:
+ +-
+
- 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:
$ openssl req -new -x509 -newkey rsa:2048 -keyout MOK.key -out MOK.crt \ - -days 3650 -subj "/CN=Your Name/" + -nodes -days 3650 -subj "/CN=Your Name/" $ openssl x509 -in MOK.crt -out MOK.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. After you type the first command, it will prompt you for a passphrase. 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.
+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.
- 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. +
- 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 the rEFInd binary by typing sbsign --key MOK.key --cert MOK.crt --output grubx64.efi refind_x64.efi, adjusting the paths as necessary to the keys and the rEFInd binary. Note that you're giving the signed rEFInd binary the filename grubx64.efi. This is necessary to launch rEFInd from shim. +
- 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. -
- Follow the manual 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. +
- 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. -
- 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. +
- Check your refind.conf file to ensure that the showtools option is either commented out or includes mok_tool among its options. -
- 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: - -
- 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 MOK.cer file you copied to the ESP earlier. - -
- Select MOK.cer. You can type 1 to view your 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. +
- 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.
- -
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. It 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, 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.
+At this point you should be able to launch the binaries you've signed. Unfortunately, there can still be problems at this point....