Managing EFI Boot Loaders for Linux:
Dealing with Secure Boot

by Rod Smith,

Originally written: 11/4/2012; last update: 2/22/2015

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 can improve system security, but that also has the potential to cause a great deal of confusion and trouble: Secure Boot. As the name implies, Secure Boot is intended as a security feature. By its very nature, though, Secure Boot can also make it harder to boot Linux, particularly on commodity PCs that ship with Windows pre-installed. This page provides an overview of what Secure Boot is and how the Linux community is responding to it. Although Secure Boot is developing less rapidly than it was in late 2012, when I first wrote this page, it's still a dynamic area. In other words, 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. (Microsoft uses another key to sign its own 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, then 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 saw occasional overwrought posts. By early 2015, the hysteria has died down and has been replaced by a combination of frustration when users run into problems and real-world knowledge of workarounds and even ways to employ Secure Boot for your own benefit. 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. (The last of these options is covered in much greater detail on the next page in this document, Controlling Secure Boot.)

Disabling Secure Boot

If you aren't convinced that Secure Boot will improve your system's security, or if it's simply causing you too many problems, 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. Instead, I describe the options on four computers I own that support Secure Boot: the ASRock FM2A88M Extreme4+ motherboard, the ASUS P8H77-I motherboard, the MSI A88X-G43 motherboard, and the Lenovo IdeaPad U530 Touch laptop computer. I present details of all of these systems here in the hopes that one of them will be similar enough to whatever you're facing to be helpful.

Disabling Secure Boot on the ASRock FM2A88M Extreme4+ Motherboard

The first step to disabling Secure Boot on any computer is discovering how to enter the firmware setup utility. This motherboard, unlike some, presents a boot-time prompt to hit F11 to do this, whereupon you're greeted by the colorful main setup screen. Using the keyboard or mouse, you should select the Security tab, which produces the screen shown here:

The ASRock Secure Boot menu is easy to find.

To disable Secure Boot, click the Enabled button near the middle of the screen. You'll then be able to select Enabled or Disabled; select the latter. Once this is done, select the Exit tab and choose the option to exit while saving your changes.

Disabling Secure Boot on the ASUS P8H77-I Motherboard

The ASUS P8H77-I motherboard enables you to enter the setup utility by pressing Del or F2 during startup. The motherboard defaults to booting in what it calls EZ Mode, but to disable Secure Boot, you must first press F7 to enter Advanced Mode (unless of course you've already changed this default). That done, you can click the Boot tab and then scroll down to around the middle of the option list (which is likely to scroll—note the scroll bar in the screen shot), where you'll see an item called Secure Boot, as shown below. (Early versions of this model's firmware called it Security Boot Parameters.)
The ASUS Secure Boot menu is logically labeled.

Selecting the Secure Boot option opens another menu, in which you select the OS Type—ASUS seems to think that Secure Boot is a Windows-only feature, so Secure Boot is enabled when the OS Type is set to Windows UEFI mode and disabled when it's set to Other OS. (Earlier versions of this firmware used Other Legacy & UEFI to disable Secure Boot.)

ASUS considers Secure Boot active when the OS Type is set to
    Windows UEFI mode.

When you've made your changes, press the F10 key to save them and reboot.

Disabling Secure Boot on the MSI A88X-G43 Motherboard

To enter the firmware setup utility in the MSI A88X-G43, you press the Delete key while the system starts up. The result is an unusually flashy tool. Use the keyboard or mouse to select the large Settings item on the left of the screen. This yields a series of menus in the center. From these menus, select Advanced -> Windows 8/8.1 Configuration -> Secure Boot -> Secure Boot Support. The resulting screen looks like this:

MSI, like ASUS, seems to think that Secure Boot is a
    Windows-specific feature.

When you select the Secure Boot Support option, you can set it to Enabled or Disabled. Once you've done this, use the Esc key to back out of the menus to the top Settings menu, from which you can select Save & Exit, which in turn presents various exit options. You should pick the option to save your changes and reboot.

Disabling Secure Boot on the Lenovo IdeaPad U530 Touch Laptop

The Lenovo U530 has a firmware user interface that more closely resembles a traditional BIOS setup utility than do the interfaces of the other computers described here. To enter it, you can hit the Fn+F2 key as the computer boots. Once you've entered the setup utility, use the right arrow key to select the Security tab. The result looks like this:

Lenovo's UEFI user interface is a simple text-mode affair.

The Secure Boot option is clearly labeled and easily changed from Enabled to Disabled by using the arrow and Enter keys. When you're done, press Fn+F10 to save the change and exit.

Final Thoughts on Disabling Secure Boot

Of course, unless you happen to have one of these specific computers, or one with a nearly-identical UEFI implementation, chances are you won't see menus exactly like those I've just described. Fortunately, most are fairly straightforward, like these. A few present scary warnings against a red background if you attempt to disable Secure Boot. I've seen reports from people who've been unable to find Secure Boot options, but I don't know if this was because their computers hid them particularly well or because they were actually missing. Note that options sometimes don't appear until you've set other options in a particular way. The ASUS board's need to enter Advanced Mode is one example of this. The bottom line is that you may need to experiment to locate your Secure Boot options.

Most Linux distributions will install just fine with Secure Boot active. Scenarios in which it makes the most sense to disable Secure Boot include the following:

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 2015, I know of two signed boot loaders intended for use with Linux: Fedora's Shim program (which is also being used by Ubuntu, SUSE, Sabayon, ALT, and others) and the Linux Foundation's "PreLoader." As I write, several signed versions of Shim are available, as is at least one signed version of PreLoader. I also describe how to verify a signed boot loader's signature to be sure it is what you think it is.

Using the Shim Program

Ideally, Shim is easy to use, in which case you need only read the Initial Shim Setup section—and you can even ignore parts of that section. If you have more advanced needs or run into problems, though, you may need to know how to sign your own binaries and verify your or others' binaries.

Initial Shim Setup

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 and later restrict actions that some Linux users take for granted. For instance, Linux kernel modules must be signed, which complicates 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. Most other distributions ship kernels that are relatively unencumbered by added security restrictions.

As a practical matter, if you want to use Shim, you have two choices: You can run a distribution that provides its own signed version of Shim, such as Fedora 18 or later or Ubuntu 12.10 or later; or you can run a signed version from such a distribution or from another source, add your own MOK, and sign whatever binaries you like. This first option is quite straightforward if you happen to want to use a distribution that ships with Shim, and it requires little extra elaboration. Ideally, it will Just Work. If it doesn't, that could indicate a bug in Shim or in your UEFI implementation. In such a case, disabling Secure Boot may be your best bet, at least in the short term as you investigate the cause of the problem.

If you're dual-booting with multiple Linux distributions or if you want to use a distribution that doesn't provide a pre-signed Shim, you'll have to jump through some extra hoops:

  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 disc in its rescue mode can work for the first of these options.)
  2. The Shim you install can launch boot loaders and validate kernels included with the distribution from which you got it. Other boot loaders and kernels fall into one of two categories, each of which requires its own preliminaries:
  3. If it's not already installed, install Shim. Treat shim.efi or shimx64.efi like any other boot loader, as described in the EFI Boot Loader Installation page.
  4. Along with Shim, install MokManager. This program should come with Shim, and should reside, under the name MokManager.efi, in the same directory as the Shim binary. As the name suggests, this program manages MOKs. I describe its use shortly.
  5. If necessary, sign the follow-on boot loader, as well as any unsigned kernel you want to launch. This step is necessary only if the follow-on boot loader and kernel are not already signed—for instance, if you compiled them yourself.
  6. If Shim's follow-on boot loader is not already installed, copy it to the filename grubx64.efi in the same directory that holds shim.efi. Shim is designed to launch GRUB 2, but it can launch other boot loaders, provided they're named grubx64.efi. Note, however, that most older follow-on boot loaders, such as ELILO, won't honor the Secure Boot settings. rEFInd is designed to honor Secure Boot settings. Unfortunately, gummiboot doesn't "talk" to Shim, so it can't be used as a follow-on boot program. (You can use gummiboot with PreLoader, though.) Note that you need not register the follow-on boot loader directly with the firmware by using efibootmgr. Such a registration might cause warnings of Secure Boot failures or even system hangs on some computers.
  7. 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.
  8. 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:
    MokManager's user interface is crude but effective.
    Note that the preceding figure shows an early version of MokManager, featuring a user interface that makes an Apple II look sophisticated. Somewhere between version 0.4 and 0.7, the user interface was upgraded to the MS-DOS era, and began to look like this:
    More recent versions of MokManager have an improved
    user interface.
  9. Each of the lines with a long awkward string represents a disk partition. Select one and you'll see a list of files and directories. Continue selecting subdirectories until you find the public key file you obtained or created and copied to the ESP earlier.
  10. Select the public key file. MokManager will ask for verification that you want to enroll the key. Provide it.
  11. Back out of any directories you entered and return to the MokManager main menu.
  12. 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 program 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.

Signing Your Binaries

If you want to boot a kernel you compile yourself or launch an OS that doesn't sign its boot loader, you'll need to sign the relevant binaries. To begin this process, you must first prepare a set of keys with openssl, as described earlier. You'll also need the sbsigntool package, which comes standard with some distributions. If yours isn't one of them, you can obtain binaries for several distributions from the OpenSUSE Build Service or download the source code from this page.

Once you've installed the sbsigntool package and created keys, you can sign a binary with a command like the following:

$ sbsign --key ~/efitools/MOK.key --cert ~/efitools/MOK.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 (MOK.key and MOK.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. (Such warnings seem to be less common in 2015 than they were a couple of years ago.) 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 recompile your binary using a more recent version of GNU-EFI.

If you're using rEFInd, you must sign not just the boot manager binary, but also the boot loaders that it launches, 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 manager is intended to launch. rEFIt and gummiboot can't "talk" to Shim, and so can't launch follow-on boot loaders and kernels that are signed only with MOKs. Stock versions of ELILO, GRUB Legacy, and older builds of GRUB 2 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, at least when launching Linux. Most recent versions of GRUB 2 communicate with Shim for authenticating Linux kernels and so will refuse to launch a Linux kernel that's not been signed, at least when GRUB is launched via Shim.

Once you've signed your binaries, you should install them to your ESP much as you would an unsigned EFI binary. Signed binaries should work fine even on systems on which you've disabled Secure Boot. Note, however, that anything launched directly from the firmware (that is, registered with efibootmgr or launched using the fallback filename) must be signed with a key in the firmware. Boot loaders signed by a MOK can be launched directly from Shim or from rEFInd (if rEFInd is launched from Shim).

As a side note, the pesign utility, available from 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.

Verifying Your Boot Loaders

You can use the Secure Boot signature on an EFI binary to verify the authenticity of the binary. This is useful both in diagnosing boot problems (since an improperly-signed binary won't boot) and to check that the binary comes from the claimed source.

To verify a binary, you'll need two things: A public key file matched to the private key that was used to sign the binary and a program called sbverify. As noted earlier, I provide a collection of public key files with rEFInd; see the rEFInd git repository for access to individual keys. Note that for verification, you'll need a text-mode PEM file with a .crt extension, not the .cer or .der file needed when adding the key to the MOK list.

The sbverify program is available with some distributions, such as Ubuntu, as part of the sbsigntool package. OpenSUSE binaries are available from the OpenSUSE Build Service. If necessary, you can obtain the source code from various sites. If you have git installed, typing git:// should pull it down.

Once you've installed sbsigntool you can use 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 can't find a key in the form of a text-mode PEM file, or if you don't trust that what you've got is equivalent to the .cer or .der file, 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 or the patience to deal with the Byzantine process of getting a binary signed. PreLoader is 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. Obtain PreLoader. Pre-signed binaries are available from its download site. Note, however, that these pre-signed binaries are quite old. The program has been updated since then, but I'm not aware of any more recent official signed binaries.
  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 probably 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 those kernels 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.

Replacing or Supplementing Your Firmware's Keys

It's possible to replace Microsoft's keys with your own, which enables you to gain the benefits of Secure Boot without using either Shim or PreLoader. 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 distribute binaries signed with Microsoft's keys. It's also possible to add your own keys to those built into the firmware, without removing Microsoft's keys. This is useful if Shim or PreLoader malfunctions or if you want to use a boot program, such as gummiboot, that doesn't work well with Shim. Broadly speaking, there are three main steps to this process: generating your own keys, signing your binaries, and installing your keys in your firmware. The first two of these steps are also necessary if you want to sign your own binaries for use with Shim.

Unfortunately, there are significant model-to-model differences in Secure Boot implementations and available tools, which means that describing this approach to managing Secure Boot is complex. Thus, I've written a separate page covering the process in detail.

Replacing your firmware's keys doesn't take much more effort than using Shim if you would need to sign your own binaries for some reason—say, if you're using a distribution such as Gentoo that doesn't provide pre-signed binaries. It also has some security advantages, particularly if you don't need Microsoft's keys. On the other hand, it's a lot more hassle than using Shim if you just want to get a Shim-using distribution up and running quickly. Overall, I recommend this approach only for those who are fairly technically inclined.

Concluding Thoughts

In early 2015, 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. Using the Shim program looks like the best way to do this for users of Fedora, OpenSUSE, Ubuntu, and other distributions that support Shim. If you're using another distribution or are having trouble booting multiple distributions, 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. This approach is the hardest one to implement, particularly if your computer's firmware setup utility lacks the ability to add keys.

Go on to "Controlling Secure Boot"

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 Thanks.

Return to my main Web page.