Managing EFI Boot Loaders for Linux:
Dealing with Secure Boot

by Rod Smith, rodsmith@rodsbooks.com

Originally written: 11/4/2012; last update: 7/6/2013

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!

Donate $1.00 Donate $2.50 Donate $5.00 Donate $10.00 Donate another value
Donate with PayPal
Donate with PayPal
Donate with PayPal
Donate with PayPal
Donate with PayPal

This page is part of my Managing EFI Boot Loaders for Linux document. If a Web search has brought you to this page, you may want to start at the beginning.

In addition to implementing a new boot protocol, UEFI adds a new feature that has the potential to cause a great deal of confusion and trouble, but that can also improve system security: Secure Boot. As the name implies, Secure Boot is intended as a security feature. Its potential to improve system security is greatest on Windows systems. By its very nature, though, Secure Boot can also make it harder to boot Linux. This page provides an overview of what Secure Boot is and how the Linux community is responding to it. Be aware that these matters are changing rapidly, so if you read this more than a few months into 2013, be aware that things may have changed!

What Is Secure Boot?

For decades, PCs have been plagued by viruses, worms, and other malware. Some of the earliest viruses for PCs spread as boot sector viruses: They resided as code in the boot sectors of floppy disks and spread from one computer to another when users booted their computers using infected DOS floppies. Although other modes of virus transmission gained prominence as floppies faded in importance and Internet connections became common, pre-boot malware has always had its advantages to malware authors. By executing before an OS kernel gains control of the computer, malware can "hide out" in ways that aren't possible once an OS has taken over. Pre-boot malware can become invisible to the OS, making it virtually impossible for virus scanners to detect the malware—at least, not without rebooting into an emergency system that's not infected.

BIOS provides few protections against infection by pre-boot malware; in the BIOS boot path, the OS implicitly trusts whatever executes as the boot loader. Until late 2012, this has been true of most production EFI implementations, too. Secure Boot, though, is designed to add a layer of protection to the pre-boot process. With Secure Boot active, the firmware checks for the presence of a cryptographic signature on any EFI program that it executes. If the cryptographic signature is absent, doesn't correspond to a key held in the computer's NVRAM, or is blacklisted in the NVRAM, the firmware refuses to execute the program. Of course, this is simply the start of the process; a trusted EFI boot loader must continue the boot process in a secure fashion, leading ultimately to an OS that is itself secure. A malware author would need to get the malware signed, which would be difficult if users control their own system keys. Thus, pre-boot malware can be blocked. There are a lot of ways for things to go wrong higher up the chain, but Secure Boot at least provides a foundation from which to secure the computer as a whole—at least, in theory!

The description of Secure Boot in the UEFI specification doesn't provide any mechanism to create a web of trust for its keys. Based on the UEFI specification alone, one might think that Secure Boot would be implemented in a site-by-site fashion; administrators at a site could sign the boot loaders that they use, thus locking out malware authors. Microsoft, however, included a requirement in its Windows 8 certification program that vendors ship computers with Secure Boot enabled. As a practical matter, this means that vendors must include Microsoft's keys on their computers, and unless vendors include other keys, only boot loaders signed by Microsoft will work.

Fortunately, things aren't quite as bad as this might seem. Microsoft has partnered with Verisign to manage boot loader signing. Anybody can pay $99 to Verisign to obtain the means to sign an unlimited number of binaries such that they'll run using Microsoft's key—or more precisely, a key that Microsoft uses to sign third-party binaries. Furthermore, Microsoft requires that x86 and x86-64 computers provide the means to completely disable Secure Boot, giving users control over the process. (ARM users aren't so lucky; Microsoft requires that Secure Boot can not be disabled on ARM systems bearing a Windows 8 logo.)

The initial public discussion of these matters was sparked by a blog post by Matthew J. Garrett, a Red Hat developer, in September of 2011. Much of the initial discussion on Web forums and other public meeting places was downright panicky, and even a year later I see occasional overwrought posts. I urge calm; as described on this page, there are at least three ways to deal with Secure Boot: disable it, use a pre-signed boot loader, or use your own keys.

Disabling Secure Boot

If you aren't convinced that Secure Boot will improve your system's security, you might want to disable the feature entirely. Given the fact that most malware targets Windows, this approach is most reasonable on computers that don't run Windows. You'll have to be comfortable navigating your firmware's setup screens to do this. Unfortunately, there's no standardization in where Secure Boot options might be located or what they might be called; therefore, I can't provide a procedure that will work for every computer. I can, however, describe the options on one computer I own that supports Secure Boot: The ASUS P8H77-I motherboard. This board ships with Secure Boot options disabled, but based on my experimentation, I can see how it would probably ship if it were used on a computer with Windows 8 pre-installed. Based on those assumptions, to disable Secure Boot, you should:

  1. Enter the computer's firmware utility by pressing Del during the initial stages of the boot process (before any boot loader appears). Some computers use other keys for this purpose; examine your early boot-time messages or read your computer's manual to learn what to use.
  2. If you're configured to boot in EZ Mode, press F7 to enter Advanced Mode.
  3. Click the Boot tab.
  4. Click Security Boot Parameters near the bottom-left of the screen. (It's conceivable you'll need to scroll down to see this on some systems.)
  5. Change OS Type from Windows 8 UEFI to Other Legacy & UEFI. The Secure Boot Mode and Key Management options should disappear.
  6. Press the F10 key to save your changes and reboot the computer.

Of course, your computer's firmware is likely to be different from mine. Your best bet if you want to disable Secure Boot is to study your own system's firmware options. Your user manual might or might not be of any help. In the case of my ASUS P8H77-I, the manual makes no mention of Secure Boot options; I had to figure this out by trial and error. I've heard of implementations that are both better and worse than the one in my ASUS. On the "better" side, some label the option with a fairly obvious name of Secure Boot and options of Enabled and Disabled. On the "worse" side, I've heard of others that produce scary-sounding messages in red when you try to disable Secure Boot, or that require booting into Windows and running a Windows program before you can access the firmware.

Using a Signed Boot Loader

Using a boot loader signed with Microsoft's key is the simplest and most direct approach to dealing with Secure Boot; however, it's also the most limiting approach. Depending on what signed boot loader you use, you'll have to deal with boot-time confirmation whenever you try to boot an unsigned boot loader or be limited in what OSes and kernels you can boot. As of early 2013, I know of two signed boot loaders intended for use with Linux: Fedora's shim program (which is also being used by Ubuntu, SUSE, and Sabayon) and the Linux Foundation's "PreLoader." As I write, a signed version of shim is available, but the PreLoader has yet to be released as a signed binary. I also describe how to verify a signed boot loader's signature to be sure it is what you think it is.

Using the Fedora Shim Program

To adhere to the goals of Secure Boot, a Linux boot loader should provide authentication of the Linux kernel, and a Linux distribution should provide further security measures in the kernels it provides. Unfortunately, these goals are at odds with the open source philosophy of freedom and user control of their computers. Thus, a Secure Boot solution for Linux must balance these two goals. Fedora designed its shim program to do just that. It does so by supporting three different types of keys:

The whole point of Secure Boot is to prevent malware from gaining control of the computer. Therefore, when booting with Secure Boot active, Fedora 18 restricts actions that some Linux users take for granted. For instance, Linux kernel modules must be signed, which will complicate use of third-party kernel drivers, such as those needed by Nvidia's and AMD/ATI's proprietary video drivers. To launch a locally-compiled kernel, you must sign it with a MOK and register that MOK with the system. The extent of such restrictions is entirely up to those who develop and sign the boot loader launched by shim and the kernel launched by that boot loader, though. Some distributions are likely to ship kernels that are relatively unencumbered by added security restrictions.

In addition to Fedora (and presumably eventually Red Hat Enterprise Linux), SuSE and Ubuntu have announced that they'll be using the shim boot loader—in fact, Ubuntu 12.10 already uses an early version that doesn't support MOKs. (See this blog post for an analysis of it in action.) Signed versions of shim should be available in versions of these distributions released in late 2012 and thereafter.

As a practical matter, if you want to use shim now, you have three choices: You can run Ubuntu 12.10; you can run Fedora 18; or you can run the signed version released by Matthew Garrett, add your own MOK, and sign whatever binaries you like. Unfortunately, this process is still a bit tedious right now. In brief, it is:

  1. 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, boot using the Linux Foundation's PreLoader, or do the work from Windows. (An Ubuntu 12.10 disc in its rescue mode can work for the first of these options.)
  2. If it's not already installed, install OpenSSL on your computer. (It normally comes in a package called openssl.)
  3. 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. (The sbsigntool build process is described in more detail later, under Generating Your Own Keys.)
  4. Download shim from Matthew J. Garrett's download site or from your distribution, if it's released a signed version. (Don't use Ubuntu 12.10's version, though; as noted earlier, it's inadequate for use with MOKs.) Fedora 18's signed shim should work fine with other distributions, but it has no advantages unless you're booting Fedora 18, in which case the only reason you need to do any of these steps is if you're dual-booting with another distribution.
  5. Install shim in the normal way, as described in EFI Boot Loader Installation.
  6. Install the MokManager.efi program (which comes with shim) in the same directory that holds shim.efi. The MokManager.efi binary manages your MOKs, so failing to install this program will result in an inability to add your own keys.
  7. Create a directory for storing your MOKs and change into that directory.
  8. 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
    
  9. 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.
  10. Copy the MOK.cer file to a directory that your EFI can read, such as your computer's ESP.
  11. Change to a directory in which you've stored a binary that you want to sign with your MOK.
  12. 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.
  13. Copy your desired boot loader to shim's directory under the name grubx64.efi. This can of course be confusing if you're not using GRUB, but there's nothing to be done about it just yet. If necessary, configure your boot loader.
  14. 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 your boot loader failed verification because its key is not yet enrolled.
  15. 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:

  16. MokManager's user interface is crude but effective.
  17. 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 created and copied to the ESP earlier.
  18. Select MOK.cer. MokManager will ask for verification that you want to enroll the key. Provide it.
  19. Back out of any directories you entered and return to the MokManager main menu.
  20. 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, the boot loader you installed under the name grubx64.efi should start up in Secure Boot mode. Depending on its capabilities, it might boot any kernel it can boot as if Secure Boot were disabled, launch only boot loaders signed with the platform's Secure Boot keys, or launch EFI programs or kernels signed with regular Secure Boot keys or your own MOK.

In the future, using shim will be easier, since distributions will ship with pre-signed boot loaders, obviating the need for most of these steps. If you want to sign your own binaries, though, you'll still need to install the signing software, add your own key via MokManager, and sign the binaries you create yourself or obtain from another source.

Verifying Your Boot Loaders

The easiest way to verify that your boot loaders are properly signed is to try booting with them. You might want to check them before rebooting, though, just to be sure they'll boot. To do so, you'll need a copy of the public key that you created earlier with openssl. If the binary was signed by your distribution maintainer, you'll need a copy of their public key. If you've got the key in X509 certificate form (typically with a .crt filename extension), you can verify the binary with the sbverify command:

$ sbverify --cert keys/refind.crt refind_x64.efi
Signature verification OK

This example shows a successful verification of the refind_x64.efi binary against the keys/refind.crt public key. Failures are typically preceded by messages that describe what went wrong, often using technical language. Typically, binaries are either not signed or they're signed with a key other than the one whose public counterpart you tried to use.

If you're trying to verify a binary that was signed by your distribution provider, you'll need a copy of their public key. These are often provided in the source package for their copies of shim, so check there. I also provide several with my rEFInd boot manager, in the refind/keys subdirectory. The problem is that the most readily-accessible key files are in DER form (with a .cer or .der filename extension), but you need a text-mode PEM file (with a .crt filename extension). You can convert from one form to the other with openssl:

$ openssl x509 -in fedora-ca.cer -inform der -out fedora-ca.crt

This example converts the fedora-ca.cer file to fedora-ca.crt, which you can use to verify the authenticity of signed Fedora binaries.

Using the Linux Foundation's PreLoader

The Linux Foundation's solution to the Secure Boot problem, known as PreLoader, shares some significant similarities with shim, but it's also different in two key respects:

As a practical matter, PreLoader has an advantage if you want to launch an unsigned boot loader (as on an older Linux distribution) or if you want to distribute a bootable image but lack the funds to pay for your own signing key. It's particularly good in these cases if you're not technically inclined, since you don't need to deal with the signing keys described in reference to shim. If your distribution signs its boot loaders and/or kernels, you're better off using shim. If your boot loaders (perhaps including your kernels) seldom change, then either program will work equally well, provided you're willing to deal with signing keys.

To use PreLoader, follow these steps:

  1. Boot the computer. As with installing shim, this step can be a challenge. You may need to temporarily disable Secure Boot, use a Secure Boot-enabled emergency disc, or do the work from Windows.
  2. Download the signed PreLoader from its download site.
  3. Install the PreLoader as described on the EFI Boot Loader Installation page. You'll probably want to install it in your default boot loader's directory.
  4. Copy the HashTool.efi file from the PreLoader package to the same directory as the PreLoader binary.
  5. Rename your default boot loader as loader.efi, in the same directory as PreLoader.
  6. Reboot and, if necessary, select PreLoader as your boot option. PreLoader should launch, but it will complain that it couldn't launch loader.efi. It will then launch HashTool, which is the program that PreLoader uses to store information (hashes) on the programs you authorize.
  7. In HashTool, select the Enroll Hash option.
  8. Browse to and select the loader.efi program file. HashTool asks for confirmation; respond Yes.
  9. As a practical matter, you'll now want to repeat the previous two steps for every boot loader you might want to launch from the first one. For instance, if you're using gummiboot or rEFInd to launch Linux kernels, you'll want to select each of them for enrollment. This won't be necessary if you're using ELILO or GRUB to launch Linux kernels, but you may need to enroll a hash for a chainloaded boot loader launched from GRUB.
  10. Select Exit or Reboot System from the HashTool main menu.

At this point, your computer should reboot into your regular boot loader, and it should be able to launch kernels and follow-on boot loaders as if they were signed with your platform's Secure Boot key—provided you registered those binaries with HashTool! This last point is an important one. If you're using rEFInd or gummiboot to launch Linux kernels, you'll need to register each new kernel as you (or your distribution's package system) installs it. This fact also means that you must provide a way to launch HashTool. ELILO can't do this, but you can configure rEFIt, rEFInd, gummiboot, GRUB Legacy, and GRUB 2 to launch HashTool. In fact, rEFInd 0.6.7 and later recognize the HashTool.efi binary and provide a tag for it on the main screen.

Behind the scenes, the PreLoader is actually using the same MOK list that shim uses; PreLoader is simply using it to store program hashes rather than keys. It's possible that in the future, shim and PreLoader will acquire each others' features. At the moment, though, if you want to use keys, you should use shim, and if you want to use hashes of unsigned binaries, you should use PreLoader. In theory, you should be able to use one of these tools to launch the other, which would then launch your boot loader, thus enabling you to use either keys or hashes for authentication. I've not tried this, though.

Replacing Your Firmware's Keys

It's possible to replace Microsoft's keys with your own. This can be a useful approach if you want the benefits of Secure Boot but don't want to trust Microsoft or any of the others who will be signing binaries with the Microsoft keys. There are three main steps to this process: generating your own keys, signing your binaries, and installing your keys in your firmware. I describe each of these steps in turn. Be aware that, at least as of late 2012, the procedures required to add your own keys are fairly advanced. For instance, I describe how to obtain the necessary Linux software via git and to compile it locally. If you're not comfortable with such procedures, you may have to abandon this approach.

Generating Your Own Keys

The first step to using your own Secure Boot keys is to generate these keys. To do so, you must first install two programs, neither of which is yet widely available in binary form. The first of these programs is efitools and the second is sbsigntool (the same program used to sign MOKs). Both programs rely on the GNU-EFI library. The procedure for installing all of these packages is as follows:

  1. Go to the GNU-EFI Web site and download version 3.0r of the package (gnu-efi_3.0r.orig.tar.gz). Officially, version 3.0q or later is required; however, I've found that version 3.0s produces binaries that don't work. Perhaps this problem will be fixed in future versions of GNU-EFI or of the programs that build against it.
  2. Unpack gnu-efi_3.0r.orig.tar.gz, cd into the resulting directory, type make to build the package, and then type make install as root to install it.
  3. Change to your home directory or some other convenient location, such as /usr/src, and type git clone git://kernel.ubuntu.com/jk/sbsigntool. This step will succeed only if the git program is installed, so you may need to install it. Alternatively, you can download and install a binary package from the OpenSUSE Build Service and skip ahead to step #10.
  4. Change into the sbsigntool directory that results and type ./autogen.sh. This step retrieves additional source code into the sbsigntool directory tree. (If you get error messages about various programs, including automake, not being found, you must install the automake package and repeat this step.)
  5. Edit the configure script and change every instance of the string /usr/include/efi to /usr/local/include/efi. (You should omit this step if you installed GNU-EFI so that its include files reside in /usr/include/efi.)
  6. Type ./configure to configure the package. If this produces error messages about missing development packages, you must install them and repeat this step until it succeeds.
  7. Type make to build the package.
  8. As root, type make install to install the sbsigntool programs.
  9. Back out of the sbsigntool directory (to your home directory or /usr/src, for example).
  10. Type git clone git://git.kernel.org/pub/scm/linux/kernel/git/jejb/efitools.git. This action produces a directory called efitools containing additional source code.
  11. Change into the efitools directory.
  12. Open the Make.rules file in a text editor and replace every instance of /usr/include/efi with /usr/local/include/efi. (They're all on the INCDIR line early in the file.) While still editing this file, change every instance of /usr/lib64 to /usr/local/lib. Note both the inclusion of the local subdirectory and the change from lib64 to lib. (This change won't be necessary, or a variant of it may be needed, if you installed GNU-EFI from a binary package.)
  13. Type make. The result should be a number of files and programs, most notably including LockDown.efi, which installs keys that were generated during the build process.
  14. Back out of the efitools directory.
  15. Copy the entire efitools directory to a medium that you can read on your target computer. This could be the EFI System Partition (ESP) on the computer you used to build the files or a FAT partition on a USB flash drive, for instance.

At this point, you have Secure Boot keys in files within the efitools directory, and the LockDown.efi program will install them once you run it from an EFI shell program under the right circumstances. Of course, there's no point to locking down the firmware unless you have a signed boot loader, so that's the next step....

Signing Your Binaries

You'll presumably want to sign binaries such as grub.efi or a Linux kernel with an EFI stub loader. Furthermore, if you're planning to dual-boot with Windows or some other OS, you'll probably have to sign its boot loader, too. This is true even if it's already been signed with another key—the procedure described on this page replaces your firmware's existing keys, so existing signatures will no longer work, and you must therefore replace the signatures on existing binaries.

In any event, the procedure to sign an EFI binary is fairly straightforward, once you've installed the sbtools package and created keys by preparing the efitools package:

$ sbsign --key ~/efitools/DB.key --cert ~/efitools/DB.crt \
         --output vmlinuz-signed.efi vmlinuz.efi
warning: file-aligned section .text extends beyond end of file
warning: checksum areas are greater than image size. Invalid section table?

This example signs the vmlinuz.efi binary, located in the current directory, writing the signed binary to vmlinuz-signed.efi. Of course, you must change the names of the binaries to suit your needs, as well as adjust the path to the keys (DB.key and DB.crt).

This example shows two warnings. I don't claim to fully understand them, but they don't seem to do any harm—at least, the Linux kernel binaries I've signed that have produced these warnings have worked fine. Another warning I've seen on binaries produced with GNU-EFI also seems harmless:

warning: data remaining[1231832 vs 1357089]: gaps between PE/COFF sections?

On the other hand, the ChangeLog file for GNU-EFI indicates that binaries created with GNU-EFI versions earlier than 3.0q may not boot in a Secure Boot environment when signed, and signing such binaries produces another warning:

warning: gap in section table:
    .text   : 0x00000400 - 0x00019c00,
    .reloc  : 0x00019c91 - 0x0001a091,
warning: gap in section table:
    .reloc  : 0x00019c91 - 0x0001a091,
    .data   : 0x0001a000 - 0x00035000,
gaps in the section table may result in different checksums

If you see a warning like this, you may need to rebuild your binary using a more recent version of GNU-EFI.

If you're using rEFIt, rEFInd, or gummiboot, you must sign not just those boot manager binaries, but also the boot loaders that they launch, such as Linux kernels or ELILO binaries. If you fail to do this, you'll be unable to launch the boot loaders that the boot managers are intended to launch. Stock versions of ELILO and GRUB don't check Secure Boot status or use EFI system calls to load kernels, so even signed versions of these programs will launch any kernel you feed them. This defeats the purpose of Secure Boot, though, at least when launching Linux. At least some future versions of GRUB will communicate with shim for authenticating Linux kernels and so may refuse to launch a Linux kernel that's not been signed.

Once you've signed your binaries, you should install them to your ESP as you would an unsigned EFI binary. Signed binaries should work fine even on systems on which you've disabled Secure Boot.

As a side note, the pesign utility, available from git://github.com/vathpela/pesign.git, is an alternative to sbtools; however, because efitools is coded to use sbtools, I've barely looked at pesign. You might want to check it out if you have problems with sbtools, though.

Installing Your Own Keys

With your keys ready and your binaries signed, you can now configure your computer to use them. Unfortunately, this process is likely to vary greatly from one EFI implementation to another. The following is based on my experiences with an ASUS P8H77-I motherboard, so if you're using a different EFI implementation, you may need to look for options that are similar but not identical to those described here, or even deviate very substantially from the following instructions. With that caveat out of the way, here's how to install Secure Boot keys on at least some computers:

  1. Prepare an EFI-bootable medium that contains an EFI shell. You could install the EFI shell as EFI/BOOT/bootx64.efi or set it up so that it can be launched from the EFI's own boot manager or from rEFInd or gummiboot. Test to be sure you can enter this shell. (If Secure Boot is already enabled, you'll need to disable it first.)
  2. Enter the computer's firmware utility by pressing Del during the initial stages of the boot process (before any boot loader appears). Some computers use other keys for this purpose; examine your early boot-time messages or read your computer's manual to learn what to use.
  3. If you're configured to boot in EZ Mode, press F7 to enter Advanced Mode.
  4. Click the Boot tab.
  5. Click Security Boot Parameters near the bottom-left of the screen. (It's conceivable you'll need to scroll down to see this on some systems.)
  6. For OS Type, select Windows 8 UEFI. (Yes, even if you're not going to boot Windows.)
  7. For Secure Boot Mode, select Custom. The screen should look something like this:

  8. On an ASUS motherboard, you must set a 'Custom'
    Secure Boot mode to use your own keys.
  9. Click Key Management to get to the page in which you can manage keys, as shown here:

  10. On an ASUS motherboard, you must set a 'Custom'
    Secure Boot mode to use your own keys.
  11. Set Default Key Provisioning to Disable.
  12. Click Clear Secure Boot Keys to remove any old keys.
  13. If you placed the efitools directory on a USB flash disk, insert it into the computer.
  14. Press F10 to save your changes and reboot the computer.
  15. If necessary, as the computer starts up, press F8 to enter the firmware's boot manager to select the medium you prepared to boot the EFI shell. (F8 is the key that ASUS uses in the P8H77-I to load the boot manager; this key may be different on other computers.)
  16. Launch your EFI shell.
  17. Change to the filesystem holding efitools and enter that directory. For instance, you might type fs4: followed by cd efitools.
  18. Type LockDown.efi to enter your keys into the firmware and enable Secure Boot mode. If you receive a message to the effect that the computer is not in Setup mode, then you should review the last few steps; or if you're using firmware other than ASUS', you may need to experiment to learn how to kick your system into Setup mode. Alternatively, you could try loading your various keys manually using the various Set ... from File options in the user interface.

At this point, your computer should be set up for Secure Boot. (If you haven't already installed your signed EFI binaries, though, you must do so now.) You should be able to reboot and use the signed binaries; but unsigned binaries, or those signed by anybody but you, should not run.

Concluding Thoughts

In late 2012, Secure Boot is a modest-to-major hassle for Linux users. Although it has the potential to improve security, Linux has historically not been plagued by viruses, so it's unclear that Secure Boot will be a benefit for Linux-only computers. If you dual-boot with Windows, though, you may want to keep Secure Boot enabled. In the medium and long term, using the Fedora shim program looks like the best way to do this; but as of early January 2013, the rarity of pre-signed follow-on binaries makes shim awkward to install and use. In the meantime, disabling Secure Boot is the easiest way to deal with it. Signing your own boot loaders to use the native Secure Boot mechanism and your own key set is another alternative, and one that provides you with the greatest security and flexibility; but this approach is the hardest one to implement.

In other words: It's a mess right now, but Linux developers are working to clean it up.


Go on to "Repairing Boot-Repair"

Return to "Managing EFI Boot Loaders for Linux" main page


If you have problems with or comments about this web page, please e-mail me at rodsmith@rodsbooks.com. Thanks.

Return to my main Web page.