From c8883302f06e69a8b961280b73e29b4b09cacb9d Mon Sep 17 00:00:00 2001 From: srs5694 Date: Tue, 17 Feb 2015 09:18:05 -0500 Subject: [PATCH] New FreeBSD GPT BIOS-mode boot loader detection code. Also, improvements to Secure Boot documentation and addition of KeyTool.efi as a recognized MOK management tool. --- NEWS.txt | 15 +++++ docs/refind/secureboot.html | 126 +++++++++++++++++++++--------------- refind/global.h | 2 +- refind/lib.c | 9 +++ refind/main.c | 5 +- 5 files changed, 103 insertions(+), 54 deletions(-) diff --git a/NEWS.txt b/NEWS.txt index 93f0eff..29762a7 100644 --- a/NEWS.txt +++ b/NEWS.txt @@ -1,6 +1,21 @@ 0.8.7 (?/??/2015): ------------------ +- Added detection of FreeBSD's BIOS-mode GPT boot loader. Previously, + rEFInd could detect FreeBSD's BIOS-mode MBR boot loader, which gave + FreeBSD an appropriate icon on Macs; but the GPT boot loader code is + different, so some recent FreeBSD installations showed up with generic + grey diamond icons. This change creates FreeBSD icons instead. + +- Added "Secure Boot [active|inactive]" notice to "about" menu for x86 + (32-bit) systems, since there are now a few 32-bit UEFI systems that + support Secure Boot. (AFAIK, these are mostly tablets and convertibles + such as the ASUS T100.) + +- Added KeyTool.efi and KeyTool-signed.efi to list of MOK managers. KeyTool + is the "super-deluxe" Secure Boot key and hash manager provided as part + of the efitools package. + - Fixed more instances of "invalid parameter" errors on some EFIs. - Improved Secure Boot detection in install.sh. diff --git a/docs/refind/secureboot.html b/docs/refind/secureboot.html index d2a4147..d7d3039 100644 --- a/docs/refind/secureboot.html +++ b/docs/refind/secureboot.html @@ -15,7 +15,7 @@ href="mailto:rodsmith@rodsbooks.com">rodsmith@rodsbooks.com

Originally written: 11/13/2012; last Web page update: -2/8/2015, referencing rEFInd 0.8.6

+2/16/2015, referencing rEFInd 0.8.6

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!

@@ -152,7 +152,7 @@ href="mailto:rodsmith@rodsbooks.com">rodsmith@rodsbooks.com

-

If you're using a computer that supports Secure Boot, you may run into extra complications. This feature is intended to make it difficult for malware to insert itself early into the computer's boot process. Unfortunately, it also complicates multi-boot configurations such as those that rEFInd is intended to manage. This page describes some secure boot basics and two specific ways of using rEFInd with Secure Boot: Using the shim program and using the PreLoader program. It concludes with a look at known bugs and limitations in rEFInd's Secure Boot features.

+

If you're using a computer that supports Secure Boot, you may run into extra complications. This feature is intended to make it difficult for malware to insert itself early into the computer's boot process. Unfortunately, it also complicates multi-boot configurations such as those that rEFInd is intended to manage. This page describes some Secure Boot basics and two specific ways of using rEFInd with Secure Boot: Using the Shim program and using the PreLoader program. (My separate EFI Boot Loaders for Linux page on Secure Boot covers the additional topics of disabling Secure Boot and adding keys to the firmware's own set of keys.) This page concludes with a look at known bugs and limitations in rEFInd's Secure Boot features.

Basic Issues

@@ -162,13 +162,13 @@ href="mailto:rodsmith@rodsbooks.com">rodsmith@rodsbooks.com

If you don't want it, you can disable it, at least on x86-64 PCs. If an ARM-based computer ships with -Windows 8, this isn't an option for it. Unfortunately, the shim and PreLoader programs described on this page currently support only x86-64, not x86 or ARM.

+Windows 8, this isn't an option for it. Unfortunately, the Shim and PreLoader programs described on this page currently support only x86-64, not x86 or ARM.

Through 2012, it became obvious that Secure Boot would be a feature that was controlled, to a large extent, by Microsoft. This is because Microsoft requires that non-server computers that display Windows 8 logos ship with Secure Boot enabled. As a practical matter, this also means that such computers ship with Microsoft's keys in their firmware. In the absence of an industry-standard body to manage the signing of Secure Boot keys, this means that Microsoft's key is the only one that's more-or-less guaranteed to be installed on the computer, thus blocking the ability to boot any OS that lacks a boot path through Microsoft's signing key.

-

Fortunately, Microsoft will sign third-party binaries with their key—or more precisely, with a key that Microsoft uses to sign third-party binaries. (Microsoft uses another key to sign its own binaries, and some devices, such as the Microsoft Surface tablet, lack the third-party Microsoft key.) A payment of $99 to Verisign enables a software distributor to sign as many binaries as desired. Red Hat (Fedora), Novell (SUSE), and Canonical (Ubuntu) are all using this system to enable their boot loaders to run. Unfortunately, using a third-party signing service is an awkward solution for open source software. In fact, for this very reason two separate programs exist that shift the Secure Boot "train" from Microsoft's proprietary "track" to one that's more friendly to open source authors. Both of these programs (shim and PreLoader) are available in binary form signed by Microsoft's key. Shim enables the computer to launch binaries that are signed by a key that's built into it or that the user adds to a list known as the Machine Owner Key (MOK) list. PreLoader enables the computer to launch binaries that the user has explicitly identified as being OK. Distributions beginning with Ubuntu 12.10 (and 12.04.2), Fedora 18, and OpenSUSE 12.3 use shim, although Ubuntu ships with an early version of shim that's useless for launching rEFInd, at least through Ubuntu 13.04. To the best of my knowledge, no major distribution uses PreLoader, but it may see use on live CDs and is easier to set up if you're not using a distribution that supports shim.

+

Fortunately, Microsoft will sign third-party binaries with their key—or more precisely, with a key that Microsoft uses to sign third-party binaries. (Microsoft uses another key to sign its own binaries, and some devices, such as the Microsoft Surface tablet, lack the third-party Microsoft key.) A payment of $99 to Verisign enables a software distributor to sign as many binaries as desired. Red Hat (Fedora), Novell (SUSE), and Canonical (Ubuntu) are all using this system to enable their boot loaders to run. Unfortunately, using a third-party signing service is an awkward solution for open source software. In fact, for this very reason two separate programs exist that shift the Secure Boot "train" from Microsoft's proprietary "track" to one that's more friendly to open source authors. Both of these programs (Shim and PreLoader) are available in binary form signed by Microsoft's key. Shim enables the computer to launch binaries that are signed by a key that's built into it or that the user adds to a list known as the Machine Owner Key (MOK) list. PreLoader enables the computer to launch binaries that the user has explicitly identified as being OK. Distributions beginning with Ubuntu 12.10 (and 12.04.2), Fedora 18, and OpenSUSE 12.3 use Shim, although the Ubuntu initially shipped with an early version of Shim that's useless for launching rEFInd. (Current versions of Ubuntu ship with more flexible versions of Shim.) PreLoader is used by some smaller and more specialized distributions, such as Arch Linux. You can switch from one to the other if you like, no matter what your distribution uses by default.

-

There are three ways to sign a binary that will get it launched on a computer that uses shim:

+

There are three ways to sign a binary that will get it launched on a computer that uses Shim:

-

All three key types are the same in form—shim's built-in keys and MOKs are both generated using the same tools used to generate Secure Boot keys. The keys can be generated with the common openssl program, but signing EFI binaries requires a rarer program called sbsign or pesign. If you use shim with a distribution that doesn't support this tool, you'll need to either sign the kernels yourself, which can be a hassle, or launch the kernels by way of a boot loader that doesn't check for signatures, such as ELILO.

+

All three key types are the same in form—Shim's built-in keys and MOKs are both generated using the same tools used to generate Secure Boot keys. The keys can be generated with the common openssl program, but signing EFI binaries requires either of two rarer programs: sbsign or pesign. If you use Shim with a distribution that doesn't support Secure Boot, you'll need to either sign the kernels yourself, which can be a hassle, or launch the kernels by way of a boot loader that doesn't check for signatures, such as ELILO.

-

Shim's author is working on merging it and PreLoader. Thus, future versions of shim may provide the advantages of both programs.

+

Shim's author is working on merging it and PreLoader. Thus, future versions of Shim may provide the advantages of both programs.

-

PreLoader is easier to set up on a distribution that doesn't support shim because PreLoader doesn't rely on keys; instead, you tell it which binaries you trust and it will let you launch them. This works well on a system with boot managers, boot loaders, and kernels that seldom change. It's not a good solution for distribution maintainers, though, because it requires that users manually add binaries to PreLoader's list of approved binaries when the OS is installed and every time those binaries change. Also, PreLoader relies on a helper program, HashTool, to enroll hashes. (This is Geek for "tell the computer that a binary is OK.") Unfortunately, HashTool can enroll hashes only from the partition from which it was launched, so if you want to use rEFInd to launch Linux kernels directly, it's easiest if you mount your EFI System Partition (ESP) at /boot in Linux or copy your kernels to the ESP. Another approach is to copy HashTool.efi to the partition that holds your kernel and rename it to almost anything else. rEFInd will then treat it like an OS boot loader and create a menu entry for it, enabling you to launch it as needed.

+

PreLoader is easier to set up on a distribution that doesn't support Shim because PreLoader doesn't rely on keys; instead, you tell it which binaries you trust and it will let you launch them. This works well on a system with boot managers, boot loaders, and kernels that seldom change. It's not a good solution for distribution maintainers, though, because it requires that users manually add binaries to PreLoader's list of approved binaries when the OS is installed and every time those binaries change. Also, PreLoader relies on a helper program, HashTool, to enroll hashes. (This is Geek for "tell the computer that a binary is OK.") Unfortunately, the initial (and, as far as I know, only signed) HashTool can enroll hashes only from the partition from which it was launched, so if you want to use rEFInd to launch Linux kernels directly, it's easiest if you mount your EFI System Partition (ESP) at /boot in Linux or copy your kernels to the ESP. Another approach is to copy HashTool.efi to the partition that holds your kernel and rename it to almost anything else. rEFInd will then treat it like an OS boot loader and create a menu entry for it, enabling you to launch it as needed.

-

Beginning with version 0.5.0, rEFInd can communicate with the shim system to authenticate boot loaders. If a boot loader has been signed by a valid UEFI Secure Boot key, a valid shim key, or a valid MOK 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.) PreLoader is designed in such a way that it requires no explicit support in rEFInd to work.

+

Beginning with version 0.5.0, rEFInd can communicate with the Shim system to authenticate boot loaders. If a boot loader has been signed by a valid UEFI Secure Boot key, a valid Shim key, or a valid MOK, rEFInd will launch it. rEFInd will also launch unsigned boot loaders or those with invalid signatures if Secure Boot is disabled in or unsupported by the firmware. (If that's your situation, you needn't bother reading this page.) PreLoader is designed in such a way that it requires no explicit support in rEFInd to work.

-

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, if you lack public keys for the boot loaders that rEFInd launches, you'll need to generate your own keys and sign your boot loaders, as described in the Managing Your MOKs section.

+

My binary builds of rEFInd version 0.5.0 and later ship signed with my own keys, and I provide the public version of this key with the rEFInd package. This can help simplify setup, since you needn't generate your own keys to get rEFInd working. The rEFInd PPA for Ubuntu ships unsigned binaries, but the installation script that runs automatically when the package is installed signs the binaries with a local key as it installs them. In either case, if you lack public keys for the boot loaders that rEFInd launches, you'll need to sign your boot loaders, as described in the Managing Your MOKs section.

Using rEFInd with Shim

 -

Because several major distributions support shim, I describe it first. You may need to adjust the rEFInd installation process to get it working with shim, especially if you're not using a distribution that uses this software. In addition to installing shim, you should know how to manage your MOKs, so I describe this topic, too. If you don't want to use shim, you can skip ahead to the section on PreLoader.

+

Because several major distributions support Shim, I describe it first. You may need to adjust the rEFInd installation process to get it working with Shim, especially if you're not using a distribution that uses this software. In addition to installing Shim, you should know how to manage your MOKs, so I describe this topic, too. If you don't want to use Shim, you can skip ahead to the section on PreLoader.

Installing Shim and rEFInd

 +

Note: rEFInd's install.sh script attempts to identify whether your computer was booted with Secure Boot active and, if it was, to locate existing Shim binaries and make use of whatever it finds. Thus, you may not need to explicitly set up Shim after you install rEFInd, although you will probably have to enroll rEFInd's key in your MOK list, as described shortly.

+

A working Secure Boot installation of rEFInd involves at least three programs, and probably four or more, each of which must be installed in a specific way:

-

If you've installed Fedora 18 or OpenSUSE 12.3 and can boot it with Secure Boot active, and if you then install rEFInd using the RPM file that I provide or by running install.sh, chances are you'll end up with a working rEFInd that will start up the first time, with one caveat: You'll have to use MokManager to add rEFInd's MOK to your MOK list, as described shortly. If you don't already have a working copy of shim on your ESP, your task is more complex. Broadly speaking, the procedure should be something like this:

+

If you've installed a distribution that provides Shim and can boot it with Secure Boot active, and if you then install rEFInd using the RPM file that I provide or by running install.sh, chances are you'll end up with a working rEFInd that will start up the first time, with one caveat: You'll have to use MokManager to add rEFInd's MOK to your MOK list, as described shortly. If you don't already have a working copy of Shim on your ESP, your task is more complex. Broadly speaking, the procedure should be something like this:

    @@ -247,9 +254,9 @@ Windows 8, this isn't an option for it. Unfortunately, the shim and PreLoader pr 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. -
  1. Download shim from Download Shim from Matthew J. Garrett's - download site or from your distribution. (Don't use Ubuntu's + download site or from your distribution. (Don't use an early 0.1 version, though; as noted earlier, it's inadequate for use with rEFInd.)
    2. @@ -273,23 +280,32 @@ Windows 8, this isn't an option for it. Unfortunately, the shim and PreLoader pr
  2. 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 + MokManager program, which Shim launched when rEFInd failed verification because its key is not yet enrolled.
  3. 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:
    4. + shown here:
    MokManager's user interface is crude but effective.
    + This user interface was used in early versions of MokManager, but + somewhere between versions 0.4 and 0.7, the user interface received an + upgrade. If you've got a more recent version, it will look more like + this: + +
    Recent versions of MokManager provide a somewhat more + user-friendly user interface.
    +
  4. 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!)
    5. + you copied to the ESP earlier. (Note that in the early user interface + the long lines can wrap and hide valid entries on the next line, so you + may need to select a disk whose entry is masked by another one!)
  5. Select refind.cer. You can type 1 to view the certificate's details if you like, or skip that and type @@ -302,15 +318,15 @@ Windows 8, this isn't an option for it. Unfortunately, the shim and PreLoader pr
-

At this point the computer may boot into its default OS, reboot, or perhaps even hang. When you reboot it, though, rEFInd should start up in Secure Boot mode. (You can verify this by selecting the About rEFInd tool in the main menu. Check the Platform item in the resulting screen; it should verify that Secure Boot is active.) You should now be able to launch any boot loader signed with a key recognized by the firmware or by shim (including any MOKs you've enrolled). If you want to manage keys in the future, rEFInd displays a new icon in the second (tools) row you can use to launch MokManager. (This icon appears by default if MokManager is installed, but if you edit showtools in refind.conf, you must be sure to include mok_tool as an option in order to gain access to it.)

+

At this point the computer may boot into its default OS, reboot, or perhaps even hang. When you reboot it, though, rEFInd should start up in Secure Boot mode. (You can verify this by selecting the About rEFInd tool in the main menu. Check the Platform item in the resulting screen; it should verify that Secure Boot is active.) You should now be able to launch any boot loader signed with a key recognized by the firmware or by Shim (including any MOKs you've enrolled). If you want to manage keys in the future, rEFInd displays a new icon in the second (tools) row you can use to launch MokManager. (This icon appears by default if MokManager is installed, but if you edit showtools in refind.conf, you must be sure to include mok_tool as an option in order to gain access to it.)

-

If you're using Ubuntu, 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.

+

If you're using rEFInd to boot multiple Linux versions, chances are you'll need to add the keys for the distributions whose Shim you're not using as MOKs. rEFInd ships with a selection of such keys and copies them to the keys subdirectory of the rEFInd installation directory on the ESP as a convenience. Note that you must enroll keys with .cer or .der filename extensions. Although .crt files contain the same information, their format is different and they cannot be used by MokManager.

Managing Your MOKs

 -

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):

+

The preceding instructions provided the basics of getting rEFInd up and running, including using MokManager to enroll a MOK on your computer. If you need to sign binaries, though, you'll have to use additional tools. The OpenSSL package provides the cryptographic tools necessary, but actually signing EFI binaries requires additional software. Two packages for this are available: sbsigntool and pesign. Both are available in binary form from this OpenSUSE Build Service (OBS) repository, and many distributions ship with at least one of them. The following procedure uses sbsigntool. To sign your own binaries, follow these steps (you can skip the first five steps if you've successfully used install.sh's --localkeys option):

    @@ -341,7 +357,7 @@ $ openssl x509 -in refind_local.crt -out refind_local.cer 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. + and are stored in /etc/refind.d/keys/.
  1. Copy the three key files to a secure location and adjust permissions such that only you can read refind_local.key. You'll need @@ -379,17 +395,17 @@ $ openssl x509 -in refind_local.crt -out refind_local.cer
-

At this point you should be able to launch the binaries you've signed. Unfortunately, there can still be problems at this point....

+

At this point you should be able to launch the binaries you've signed. Unfortunately, there can still be problems; see the upcoming section, Secure Boot Caveats, for information on them. Alternatively, you can try using PreLoader rather than Shim.

Using rEFInd with PreLoader

 -

If you want to use Secure Boot with a distribution that doesn't come with shim but the preceding description exhausts you, take heart: PreLoader is easier to set up and use for your situation! Unfortunately, it's still not as easy to use as not using Secure Boot at all, and it's got some drawbacks, but it may represent an acceptable middle ground. To get started, proceed as follows:

+

If you want to use Secure Boot with a distribution that doesn't come with Shim but the preceding description exhausts you, take heart: PreLoader is easier to set up and use for your situation! Unfortunately, it's still not as easy to use as not using Secure Boot at all, and it's got some drawbacks, but it may represent an acceptable middle ground. To get started, proceed as follows:

    -
  1. Boot the computer. As with shim, this can be a challenge; you may need +
  2. Boot the computer. As with Shim, this can be a challenge; you may need to boot with Secure Boot disabled, use a Secure Boot–enabled live CD, or do the installation from Windows.
    3. @@ -439,7 +455,7 @@ $ openssl x509 -in refind_local.crt -out refind_local.cer alt="Be sure to select the right binary when you enroll its hash." border=2>
    -

    Note: Unfortunately, HashTool's file selector can't change filesystems. Thus, if you want to boot a Linux kernel using rEFInd and PreLoader, you'll need to copy the kernel to the ESP, at least temporarily. Alternatively, as noted earlier, you can copy HashTool.efi to the directory that holds the kernels or to another directory on that partition that rEFInd scans—but be sure to rename HashTool.efi or rEFInd will ignore it. You'll then see a boot loader entry for HashTool.

    +

    Note: Unfortunately, the initial version of HashTool's file selector can't change filesystems. Thus, if you want to boot a Linux kernel using rEFInd and PreLoader, you'll need to copy the kernel to the ESP, at least temporarily. Alternatively, as noted earlier, you can copy HashTool.efi to the directory that holds the kernels or to another directory on that partition that rEFInd scans—but be sure to rename HashTool.efi or rEFInd will ignore it. You'll then see a boot loader entry for HashTool. More recent versions of HashTool can access multiple partitions, but I have yet to find a pre-signed version, so if you want to use it, you'll need to compile it yourself and then register its hash with an earlier version (or with Secure Boot temporarily disabled).

  3. Repeat the preceding two steps for any additional binaries you might want to enroll. These include any EFI filesystem drivers you're using, @@ -454,11 +470,13 @@ $ openssl x509 -in refind_local.crt -out refind_local.cer

    If you did everything right, rEFInd should now launch follow-on boot loaders and kernels, including both programs signed with the platform's Secure Boot keys and binaries that you've authorized with HashTool. If you need to authorize additional programs, you can do so from rEFInd by using the MOK utility tool icon that launches HashTool.efi from the second row of icons. (This icon should appear by default, but if you uncomment the showtools token in refind.conf, be sure that mok_tool is present among the options.)

    +

    Although PreLoader is easier to set up than Shim, particularly if you need to launch programs or kernels that aren't already signed, it suffers from the problem that you must register every new program you install, including Linux kernels if you launch them directly from rEFInd. This need can be a hassle if you update your kernels frequently, and every new registration chews up a little space in your NVRAM. Nonetheless, PreLoader can be a good Secure Boot solution for many users or if you want to build a portable Linux installation that you can use on any computer with minimal fuss.

    +

    Secure Boot Caveats

     -

    rEFInd's Secure Boot support is brand-new with version 0.5.0 of the program, 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:

    +

    rEFInd's Secure Boot originated with version 0.5.0 of the program, and was revamped for version 0.6.2, both released in late 2012. It's worked well for myself and several others with whom I've corresponded; but you might still run into problems. Some issues you might encounter include the following:

      @@ -467,10 +485,10 @@ $ openssl x509 -in refind_local.crt -out refind_local.cer support it. For months, I knew of no such implementation, but this SuperUser question indicates that at least one such implementation - exists. The board in question is old enough that it might not support - Secure Boot at all, though, so I'm not sure if this report indicates a - serious limitation or just a stray error message on a computer that - doesn't need this feature at all. + exists. Subsequent discussions on the site imply that the computer + doesn't support Secure Boot at all. The bottom line: If you encounter + the error message Failed to install override security policy, + try removing PreLoader from your boot path.
    • Under certain circumstances, the time required to launch a boot loader can increase. This is unlikely to be noticeable for the average small @@ -478,11 +496,17 @@ $ openssl x509 -in refind_local.crt -out refind_local.cer filesystems, such as Linux kernels on ext2fs, ext3fs, or ReiserFS partitions.
      • -
    • 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 and - PreLoader both work only on x86-64, and rEFInd is dependent - upon these tools. Thus, you'll have to wait for future developments if - you want to use Secure Boot on x86 or ARM computers.
      • +
    • rEFInd's own Secure Boot support is theoretically able to work on + non-x86-64 platforms; however, to the best of my knowledge, Shim + and PreLoader both work only on x86-64, and rEFInd is dependent + upon these tools. In principle, you should be able to replace + your computer's standard Secure Boot keys to use Secure Boot on + these platforms with rEFInd, but this approach will require either + built-in key-modification tools in the computer's setup utility or a + build of LockDown.efi for your platform. I've not tested this + approach on x86 or ARM, so I can't say whether it would actually + work.
    • In theory, signing Microsoft's boot loader with a MOK should work. This might be handy if you want to replace your computer's built-in keys @@ -491,11 +515,11 @@ $ openssl x509 -in refind_local.crt -out refind_local.cer
    -

    If you launch a boot loader or other program from rEFInd that relies on the EFI's standard program-launching code, that program should take advantage of shim and its MOKs. For instance, if you launch gummiboot from rEFInd (and rEFInd from shim), gummiboot should be able to launch shim/MOK-signed Linux kernels. This is not currently true if you launch gummiboot directly from shim. (You can launch gummiboot from PreLoader and it should work, though, because of technical differences between how shim and PreLoader work.)

    +

    If you launch a boot loader or other program from rEFInd that relies on the EFI's standard program-launching code, that program should take advantage of Shim and its MOKs. For instance, if you launch gummiboot from rEFInd (and rEFInd from Shim), gummiboot should be able to launch Shim/MOK-signed Linux kernels. This is not currently true if you launch gummiboot directly from Shim. (You can launch gummiboot from PreLoader and it should work, though, because of technical differences between how Shim and PreLoader work.)

    -

    My focus in testing rEFInd's Secure Boot capabilities has been on getting Linux kernels with EFI stub loaders to launch correctly. I've done some minimal testing with GRUB 2, though. I've also tested some self-signed binaries, such as an EFI shell and MokManager. (The EFI shell launches, but will not itself launch anything that's not been signed with a UEFI Secure Boot key, even with rEFInd 0.6.2. This of course limits its utility.)

    +

    My focus in testing rEFInd's Secure Boot capabilities has been on getting Linux kernels with EFI stub loaders to launch correctly. I've done some minimal testing with GRUB 2, though. I've also tested some self-signed binaries, such as an EFI shell and MokManager. (The EFI shell launches, but will not itself launch anything that's not been signed with a UEFI Secure Boot key. This of course limits its utility.)

    -

    At the moment, I consider rEFInd's shim/MOK support to be of 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.

    +

    Some of the awkwardness of using rEFInd with Secure Boot is due to the need to manage MOKs (either keys with Shim or hashes with PreLoader). Such problems would evaporate if you could get a copy of rEFInd signed with your distribution's Secure Boot key. Thus, if you're annoyed by such problems, try filing a feature request with your distribution maintainer to have them include rEFInd (and sign it!) with their official package set.

    diff --git a/refind/global.h b/refind/global.h index 506c8a6..4824445 100644 --- a/refind/global.h +++ b/refind/global.h @@ -147,7 +147,7 @@ #define ICON_SIZE_BIG 2 // Names of binaries that can manage MOKs.... -#define MOK_NAMES L"MokManager.efi,HashTool.efi,HashTool-signed.efi" +#define MOK_NAMES L"MokManager.efi,HashTool.efi,HashTool-signed.efi,KeyTool.efi,KeyTool-signed.efi" // Directories to search for these MOK-managing programs. Note that SelfDir is // searched in addition to these locations.... #define MOK_LOCATIONS L"\\,EFI\\tools,EFI\\fedora,EFI\\redhat,EFI\\ubuntu,EFI\\suse,EFI\\opensuse,EFI\\altlinux" diff --git a/refind/lib.c b/refind/lib.c index 980b51a..19e140a 100644 --- a/refind/lib.c +++ b/refind/lib.c @@ -634,6 +634,15 @@ static VOID ScanVolumeBootcode(REFIT_VOLUME *Volume, BOOLEAN *Bootable) Volume->OSIconName = L"freebsd"; Volume->OSName = L"FreeBSD"; + // If more differentiation needed, also search for + // "Invalid partition table" &/or "Missing boot loader". + } else if ((*((UINT16 *)(Buffer + 510)) == 0xaa55) && + (FindMem(Buffer, SECTOR_SIZE, "Boot loader too large", 21) >= 0) && + (FindMem(Buffer, SECTOR_SIZE, "I/O error loading boot loader", 29) >= 0)) { + Volume->HasBootCode = TRUE; + Volume->OSIconName = L"freebsd"; + Volume->OSName = L"FreeBSD"; + } else if (FindMem(Buffer, 512, "!Loading", 8) >= 0 || FindMem(Buffer, SECTOR_SIZE, "/cdboot\0/CDBOOT\0", 16) >= 0) { Volume->HasBootCode = TRUE; diff --git a/refind/main.c b/refind/main.c index a7da984..3c94ad3 100644 --- a/refind/main.c +++ b/refind/main.c @@ -166,7 +166,7 @@ static VOID AboutrEFInd(VOID) if (AboutMenu.EntryCount == 0) { AboutMenu.TitleImage = BuiltinIcon(BUILTIN_ICON_FUNC_ABOUT); - AddMenuInfoLine(&AboutMenu, L"rEFInd Version 0.8.6.2"); + AddMenuInfoLine(&AboutMenu, L"rEFInd Version 0.8.6.4"); AddMenuInfoLine(&AboutMenu, L""); AddMenuInfoLine(&AboutMenu, L"Copyright (c) 2006-2010 Christoph Pfisterer"); AddMenuInfoLine(&AboutMenu, L"Copyright (c) 2012-2015 Roderick W. Smith"); @@ -176,7 +176,8 @@ static VOID AboutrEFInd(VOID) AddMenuInfoLine(&AboutMenu, L"Running on:"); AddMenuInfoLine(&AboutMenu, PoolPrint(L" EFI Revision %d.%02d", ST->Hdr.Revision >> 16, ST->Hdr.Revision & ((1 << 16) - 1))); #if defined(EFI32) - AddMenuInfoLine(&AboutMenu, L" Platform: x86 (32 bit)"); + AddMenuInfoLine(&AboutMenu, PoolPrint(L" Platform: x86 (32 bit); Secure Boot %s", + secure_mode() ? L"active" : L"inactive")); #elif defined(EFIX64) AddMenuInfoLine(&AboutMenu, PoolPrint(L" Platform: x86_64 (64 bit); Secure Boot %s", secure_mode() ? L"active" : L"inactive")); -- 2.39.2