-
-
- 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. +
- 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 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.) +
- 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.) Fedora 18 ships with a signed shim, but I've not yet tested + it. -
- 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 shim.efi and MokManager.efi binaries to the + directory you intend to use for rEFInd—for instance, + EFI/refind on the ESP. -
- 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.) +
- 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. Be sure that rEFInd (as grubx64.efi), + shim.efi, and MokManager.efi all reside in the same + directory. -
- 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. +
- 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.) -
- 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: +
- 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. +
- 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 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. +
- 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. +
- Back out of any directories you entered and return to the MokManager + main menu.
- Select Continue boot at the main menu. @@ -174,41 +253,78 @@ href="mailto:rodsmith@rodsbooks.com">rodsmith@rodsbooks.com
- 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
+ install.sh'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.
-
- - 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. + 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 install.sh'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.
- 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. -
- 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. -
- 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. +
- As of version 0.6.2, rEFInd's own Secure Boot support is theoretically + able to work on non-x86-64 platforms; however, shim 0.2 works + only on x86-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 x86 or ARM computers. + +
- 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.
-
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 Ubuntu 12.10, you can't use its version of shim, but you can replace it with Garrett's shim. If you do so, though, you'll have to add Ubuntu's public key as a MOK, at least if you intend to launch Ubuntu's version of GRUB or launch Ubuntu-provided signed kernels. Ubuntu's public key is available in the shim_0~20120906.bcd0a4e8-0ubuntu4.debian.tar.gz tarball, as canonical-uefi-ca.der. (The filename extensions .cer and .der are interchangeable for most purposes.) I've also included this key with rEFInd, in the refind/keys subdirectory of its package file. To use this key, copy it to your ESP and enroll it with MokManager. See this blog post for further details on Ubuntu 12.10's handling of Secure Boot. 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:
+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 (you can skip the first five steps if you've used install.sh's --localkeys option):
-
-
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 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:
-
-
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.)
+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.
+ +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.)
-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.
+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.
-
copyright © 2012 by Roderick W. Smith
+copyright © 2012–2013 by Roderick W. Smith
This document is licensed under the terms of the GNU Free Documentation License (FDL), version 1.3.