From: srs5694 Date: Mon, 10 Dec 2012 18:04:35 +0000 (-0500) Subject: Refinements to installation script. X-Git-Url: https://code.delx.au/refind/commitdiff_plain/fc7f6a88a85126567c26e32da887ef968e33a96a Refinements to installation script. --- diff --git a/BUILDING.txt b/BUILDING.txt index 4109142..e5501c2 100644 --- a/BUILDING.txt +++ b/BUILDING.txt @@ -222,8 +222,8 @@ With your development system set up, you can compile rEFInd as follows: directory. (Typing "ARCH=ia32 make fs" builds IA32 filesystem drivers on an x86-64 system, provided TianoCore is properly configured, as described earlier.) The result is filesystem drivers in the filesystems - subdirectory, and also copies placed in the drivers subdirectory. You - must install the TianoCore EDK2 to build the drivers. + subdirectory, and also copies placed in the drivers_{arch} subdirectory. + You must install the TianoCore EDK2 to build the drivers. If rEFInd doesn't compile correctly, you'll need to track down the source of the problem. Double-check that you've got all the necessary development @@ -308,8 +308,8 @@ Compiling the EFI Filesystem Drivers To build all the drivers, you can type "make fs" from the main directory, which builds the drivers and places copies in both the filesystems and -drivers subdirectories. If you want to build just one driver, you can -change into the "filesystems" directory and type "make {fsname}", where +drivers_{arch} subdirectories. If you want to build just one driver, you +can change into the "filesystems" directory and type "make {fsname}", where {fsname} is a filesystem name -- "ext2", "reiserfs", "iso9660", or "hfs". To install drivers, you can type "make install" in the "filesystems" @@ -317,11 +317,13 @@ directory. This copies all the drivers to the "/boot/efi/EFI/refind/drivers" directory. Alternatively, you can copy the files you want manually. As of version 0.4.8, the install.sh script includes an optional "--drivers" option that will install the drivers along -with the main rEFInd program. +with the main rEFInd program, but to the drivers_{arch} subdirectory of the +main rEFInd installation directory. *CAUTION:* Install drivers for your system's architecture *ONLY*. Installing drivers for the wrong architecture causes some systems to hang -at boot time. +at boot time. This risk can be minimized by including the architecture code +in the drivers subdirectory name (drivers_x64 or drivers_ia32). The drivers all rely on filesystem wrapper code created by rEFIt's author, Christoph Pfisterer. Most of the drivers seem to have passed through diff --git a/docs/refind/secureboot.html b/docs/refind/secureboot.html index d254f81..7a5dc97 100644 --- a/docs/refind/secureboot.html +++ b/docs/refind/secureboot.html @@ -98,23 +98,50 @@ href="mailto:rodsmith@rodsbooks.com">rodsmith@rodsbooks.com

Basic Issues

-

Note: You don't have to use Secure Boot. 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 software described on this page currently supports only x86-64, not x86 or ARM.

+

Note: You don't have to use Secure Boot. +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 software +described on this page currently supports 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. 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) have all announced plans to take advantage of this system. Unfortunately, using a third-party signing service is an awkward solution for open source software. In fact, for this very reason Red Hat has developed a program that it calls shim that essentially shifts the Secure Boot "train" from Microsoft's proprietary "track" to one that's more friendly to open source authors. Shim is signed by Microsoft and redirects the boot process to another boot loader that can be signed with keys that the distribution maintains and that are built into shim. Fedora 18 is expected to use this system. SUSE has announced that it will use the same system, as does Ubuntu with version 12.10 and later. SUSE has contributed to the shim approach by providing expansions to shim that support a set of keys that users can maintain themselves. These keys are known as Machine Owner Keys (MOKs), and managing them is described later, in Managing MOKs. To reiterate, then, there are potentially three ways to sign a binary that will get it launched on a system that uses shim:

+

Fortunately, Microsoft will sign third-party binaries with their 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) have all announced plans to take advantage of this system. Unfortunately, using a third-party signing service is an awkward solution for open source software. In fact, for this very reason Red Hat has developed a program that it calls shim that essentially shifts the Secure Boot "train" from Microsoft's proprietary "track" to one that's more friendly to open source authors. Shim is signed by Microsoft and redirects the boot process to another boot loader that can be signed with keys that the distribution maintains and that are built into shim. Fedora 18 is expected to use this system. SUSE has announced that it will use the same system, as does Ubuntu with version 12.10 and later. SUSE has contributed to the shim approach by providing expansions to shim that support a set of keys that users can maintain themselves. These keys are known as Machine Owner Keys (MOKs), and managing them is described later, in Managing MOKs. To reiterate, then, there are potentially 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. Unfortunately, the tools used to generate these keys are still rather crude and are rarely installed on Linux systems, which is one of the reasons that rEFInd's installation script doesn't yet support setting up a Secure Boot configuration. Although it's theoretically possible to use rEFInd without signing your own binaries, this is not yet practical, because distributions don't yet provide their own signed binaries or the public MOK files you must have to enroll their keys. With any luck this will change in 2013. At the very least, many distributions will begin supporting Secure Boot in the near future, and with any luck they'll include their public MOKs for use with other distributions' versions of 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. Although it's theoretically possible to use rEFInd without signing your own binaries, this is not yet practical, because distributions don't yet provide their own signed binaries or the public MOK files you must have to enroll their keys. With any luck this will change in 2013. At the very least, many distributions will begin supporting Secure Boot in the near future, and with any luck they'll include their public MOKs for use with other distributions' versions of shim.

Because shim and MOK are being supported by several of the major players in the Linux world, I've decided to do the same with rEFInd. Beginning with version 0.5.0, rEFInd can communicate with the shim system to authenticate boot loaders. If a boot loader has been signed by a valid UEFI Secure Boot key, a valid shim key, or a valid MOK key, rEFInd will launch it. rEFInd will also launch unsigned boot loaders or those with invalid signatures if Secure Boot is disabled in or unsupported by the firmware. (If that's your situation, you needn't bother reading this page.)

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

  • MokManager—This program is included with shim 0.2 and later. It presents a crude user interface for managing MOKs, and it's launched by shim if shim can't find its default boot loader (generally grubx64.efi) or if that program isn't properly signed. In principle, this program could be signed with a Secure Boot key or a MOK, but the binary in Garrett's shim 0.2 is signed with a shim key, and I expect that versions distributed with most Linux distributions will also be signed by their respective shim keys. This program should reside in the same directory as shim.efi, under the name MokManager.efi. Although you could theoretically do without MokManager, in practice you'll need it at least temporarily to install the MOK with which rEFInd is signed.
    • -
  • rEFInd—Naturally, you need rEFInd. Because shim is hard-coded to launch a program called grubx64.efi, you must install rEFInd using that name and to the same directory in which shim.efi resides. In theory, rEFInd could be signed with a Secure Boot key, a shim key, or a MOK; however, because Microsoft won't sign binaries distributed under the GPLv3, I can't distribute a version of rEFInd signed with Microsoft's Secure Boot key; and as I don't have access to the private shim keys used by any distribution, I can't distribute a rEFInd binary signed by them. (If distributions begin including rEFInd in their package sets, though, such distribution-provided binaries could be signed with the distributions' shim keys.) Thus, rEFInd will normally be signed by a MOK. Beginning with version 0.5.0, rEFInd binaries that I provide are signed by me.
    • +
  • rEFInd—Naturally, you need rEFInd. Because shim is hard-coded to launch a program called grubx64.efi, you must install rEFInd using that name and to the same directory in which shim.efi resides. In theory, rEFInd could be signed with a Secure Boot key, a shim key, or a MOK; however, because Microsoft won't sign binaries distributed under the GPLv3, I can't distribute a version of rEFInd signed with Microsoft's Secure Boot key; and as I don't have access to the private shim keys used by any distribution, I can't distribute a rEFInd binary signed by them. (If distributions begin including rEFInd in their package sets, though, such distribution-provided binaries could be signed with the distributions' shim keys.) Thus, rEFInd will normally be signed by a MOK. Beginning with version 0.5.0, rEFInd binaries that I provide are signed by me. Beginning with version 0.5.1, the installation script provides an option to sign the rEFInd binary with your own key, provided the necessary support software is installed.
  • Your boot loaders and kernels—Your OS boot loaders, and perhaps your Linux kernels, must be signed. They can be signed with any of the three key types. Indeed, your system may have a mix of all three types—a Windows 8 boot loader will most likely be signed with Microsoft's Secure Boot key, GRUB and kernels provided by most distributions will be signed with their own shim keys, and if you use your own locally-compiled kernel or a boot loader from an unusual source you may need to sign it with a MOK. Aside from signing, these files can be installed in exactly the same way as if your computer were not using Secure Boot.
    • @@ -142,31 +169,62 @@ href="mailto:rodsmith@rodsbooks.com">rodsmith@rodsbooks.com

      -
    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, or do the work from Windows.
      2. +
    2. Boot the computer. This can be a challenge in and of itself. You may + need to use a Secure Boot–enabled Linux emergency disc, + temporarily disable Secure Boot, or do the work from Windows.
      3. + +
    3. Download rEFInd in binary form (the binary + zip or CD-R image file). If you download the binary zip file, unzip it; + if you get the CD-R image file, burn it to a CD-R and mount it.
      4. -
    4. Download rEFInd in binary form (the binary zip or CD-R image file). If you download the binary zip file, unzip it; if you get the CD-R image file, burn it to a CD-R and mount it.
      5. +
    5. Download shim from Matthew J. Garrett's + download site or from your distribution. (Don't use Ubuntu 12.10's + version, though; as noted earlier, it's inadequate for use with + rEFInd.)
      6. -
    6. Download shim from Matthew J. Garrett's download site or from your distribution. (Don't use Ubuntu 12.10's version, though; as noted earlier, it's inadequate for use with rEFInd.)
      7. +

      Tip: If you're running Linux, you can save some effort by using the install.sh script with its --shim /path/to/shim.efi option rather than installing manually, as in steps 4–6 of this procedure. If you've installed openssl and sbsign, using --localkeys will generate local signing keys and re-sign the rEFInd binaries with your own key, too. You can then use sbsign and the keys in /etc/refind.d/keys to sign your kernels or boot loaders.

      -
    7. Copy the shim.efi and MokManager.efi binaries to the directory you intend to use for rEFInd—for instance, EFI/refind on the ESP.
      8. +
    8. Copy the shim.efi and MokManager.efi binaries to the + directory you intend to use for rEFInd—for instance, + EFI/refind on the ESP.
      9. -
    9. Follow the installation instructions for rEFInd on the Installing rEFInd page; however, give rEFInd the filename grubx64.efi and register shim.efi with the EFI by using efibootmgr in Linux or bcdedit in Windows. This is most cleanly done by following the manual instructions; however, you can use the install.sh script if you subsequently rename the files and register shim.efi with efibootmgr. Be sure that rEFInd (as grubx64.efi), shim.efi, and MokManager.efi all reside in the same directory.
      10. +
    10. Follow the installation instructions for rEFInd on the Installing rEFInd page; however, give rEFInd + the filename grubx64.efi and register shim.efi with + the EFI by using efibootmgr in Linux or bcdedit in + Windows. Be sure that rEFInd (as grubx64.efi), + shim.efi, and MokManager.efi all reside in the same + directory.
      11. -
    11. Copy the refind.cer file from the rEFInd package to your ESP, ideally to a location with few other files. (The rEFInd installation directory should work fine.)
      12. +
    12. Copy the refind.cer file from the rEFInd package to your ESP, + ideally to a location with few other files. (The rEFInd installation + directory should work fine.)
      13. -
    13. Reboot. With any luck, you'll see a simple text-mode user interface with a label of Shim UEFI key management. This is the MokManager program, which shim launched when rEFInd failed verification because its key is not yet enrolled.
      14. +
    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 rEFInd failed verification + because its key is not yet enrolled.
      15. -
    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. +
    16. 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:

      17. 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 refind.cer file you copied to the ESP earlier.
      18. +
    18. 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.
      19. -
    19. Select refind.cer. You can type 1 to view the certificate's details if you like, or skip that and type 0 to enroll the key.
      20. +
    20. Select refind.cer. You can type 1 + to view the certificate's details if you like, or skip that and type + 0 to enroll the key.
      21. -
    21. Back out of any directories you entered and return to the MokManager main menu.
      22. +
    22. Back out of any directories you entered and return to the MokManager + main menu.
    23. Select Continue boot at the main menu.
      24. @@ -180,35 +238,72 @@ href="mailto:rodsmith@rodsbooks.com">rodsmith@rodsbooks.com

      Managing Your MOKs

      -

      The preceding instructions provided the basics of getting rEFInd up and running, including using MokManager to enroll a MOK on your computer. If you need to sign binaries, though, you'll have to use additional tools. The OpenSSL package provides the cryptographic tools necessary, but actually signing EFI binaries requires additional software. Two packages for this are available: sbsigntool and pesign. Both are available in binary form from this OpenSUSE Build Service (OBS) repository. The following procedure uses sbsigntool. To sign your own binaries, follow these steps:

      +

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

        -
      1. If it's not already installed, install OpenSSL on your computer. (It normally comes in a package called openssl.
        2. +
      2. If it's not already installed, install OpenSSL on your computer. (It + normally comes in a package called openssl.)
        3. -
      3. Type the following two commands to generate your public and private keys: +
      4. If you did not re-sign your rEFInd binaries with + install.sh's --localkeys option, type the following + two commands to generate your public and private keys: 
        -$ openssl req -new -x509 -newkey rsa:2048 -keyout MOK.key -out MOK.crt \
-  -nodes -days 3650 -subj "/CN=Your Name/"
-$ openssl x509 -in MOK.crt -out MOK.cer -outform DER
+$ openssl req -new -x509 -newkey rsa:2048 -keyout refind_local.key \
+  -out refind_local.crt -nodes -days 3650 -subj "/CN=Your Name/"
+$ openssl x509 -in refind_local.crt -out refind_local.cer -outform DER
        -Change Your Name to your own name or other identifying characteristics, and adjust the certificate's time span (set via -days) as you see fit. If you omit the -nodes option, the program will prompt you for a passphrase for added security. Remember this, since you'll need it to sign your binaries. The result is a private key file (MOK.key), which is highly sensitive since it's required to sign binaries, and two public keys (MOK.crt and MOK.cer), which can be used to verify signed binaries' authenticity. The two public key files are equivalent, but are used by different tools—sbsigntool uses MOK.crt to sign binaries, but MokManager uses MOK.cer to enroll the key.
        5. - -
      5. Copy the three key files to a secure location and adjust permissions such that only you can read MOK.key. You'll need these keys to sign future binaries, so don't discard them.
        6. - -
      6. Copy the MOK.cer file to your ESP, ideally to a location with few other files. (MokManager's user interface becomes unreliable when browsing directories with lots of files.)
        7. - -
      7. 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.
        8. - -
      8. 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.
        9. - -
      9. Copy your signed binary to a suitable location on the ESP for rEFInd to locate it. Be sure to include any support files that it needs, too.
        10. - -
      10. Check your refind.conf file to ensure that the showtools option is either commented out or includes mok_tool among its options.
        11. - -
      11. Reboot. You can try launching the boot loader you just installed, but chances are it will generate an Access Denied message. For it to work, you must launch MokManager using the tool that rEFInd presents on its second row. You can then enroll your MOK.cer key just as you enrolled the refind.cer key.
        12. + Change Your Name to your own name or other identifying + characteristics, and adjust the certificate's time span (set via + -days) as you see fit. If you omit the -nodes option, + the program will prompt you for a passphrase for added security. + Remember this, since you'll need it to sign your binaries. The result + is a private key file (refind_local.key), which is highly + sensitive since it's required to sign binaries, and two public keys + (refind_local.crt and refind_local.cer), which can be + used to verify signed binaries' authenticity. The two public key files + are equivalent, but are used by different + tools—sbsigntool uses refind_local.crt to sign + binaries, but MokManager uses refind_local.cer to enroll the + key. If you used install.sh's --localkeys option, + this step is unnecessary, since these keys have already been created + and are stored in /etc/refind.d/keys. + +
      12. Copy the three key files to a secure location and adjust permissions + such that only you can read refind_local.key. You'll need + these keys to sign future binaries, so don't discard them.
        13. + +
      13. Copy the refind_local.cer file to your ESP, ideally to a + location with few other files. (MokManager's user interface becomes + unreliable when browsing directories with lots of files.)
        14. + +
      14. 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.
        15. + +
      15. Sign your binary by typing sbsign --key + refind_local.key --cert refind_local.crt --output binary-signed.efi binary.efi, adjusting the + paths to the keys and the binary names.
        16. + +
      16. Copy your signed binary to a suitable location on the ESP for rEFInd to + locate it. Be sure to include any support files that it needs, + too.
        17. + +
      17. Check your refind.conf file to ensure that the + showtools option is either commented out or includes + mok_tool among its options.
        18. + +
      18. Reboot. You can try launching the boot loader you just installed, but + chances are it will generate an Access Denied message. For it + to work, you must launch MokManager using the tool that rEFInd presents + on its second row. You can then enroll your refind_local.cer + key just as you enrolled the refind.cer key.
      diff --git a/filesystems/Make.tiano b/filesystems/Make.tiano index 35e487a..9eea221 100644 --- a/filesystems/Make.tiano +++ b/filesystems/Make.tiano @@ -96,8 +96,8 @@ $(BUILDME): $(DLL_TARGET) $(GENFW) -e UEFI_DRIVER -o $(BUILDME) $(DLL_TARGET) # $(OBJCOPY) -j .text -j .sdata -j .data -j .dynamic -j .dynsym -j .rel \ # -j .rela -j .reloc --rename-section .data=.hii --target=efi-bsdrv-$(ARCH) $< $@ - mkdir -p ../drivers - cp $(BUILDME) ../drivers + mkdir -p ../drivers_$(FILENAME_CODE) + cp $(BUILDME) ../drivers_$(FILENAME_CODE) endif diff --git a/install.sh b/install.sh index 76fc27b..7e2fef4 100755 --- a/install.sh +++ b/install.sh @@ -10,10 +10,11 @@ # "--esp" to install to the ESP rather than to the system's root # filesystem. This is the default on Linux # "--usedefault {devicefile}" to install as default -# (/EFI/BOOT/BOOTX64.EFI and similar) to the specified -# device (/dev/sdd1 or whatever) without registering with -# the NVRAM +# (/EFI/BOOT/BOOTX64.EFI and similar) to the specified device +# (/dev/sdd1 or whatever) without registering with the NVRAM. # "--drivers" to install drivers along with regular files +# "--shim {shimfile}" to install a shim.efi file for Secure Boot +# "--localkeys" to re-sign x86-64 binaries with a locally-generated key # # The "esp" option is valid only on Mac OS X; it causes # installation to the EFI System Partition (ESP) rather than @@ -26,7 +27,7 @@ # # Revision history: # -# 0.5.1 -- Added --shim option +# 0.5.1 -- Added --shim & --localkeys options # 0.5.0 -- Added --usedefault & --drivers options & changed "esp" option to "--esp" # 0.4.5 -- Fixed check for rEFItBlesser in OS X # 0.4.2 -- Added notice about BIOS-based OSes & made NVRAM changes in Linux smarter @@ -173,7 +174,8 @@ CopyRefindFiles() { CopyShimFiles fi if [[ $InstallDrivers == 1 ]] ; then - cp -r $RefindDir/drivers_* $InstallDir/$TargetDir/ + cp -r $RefindDir/drivers_* $InstallDir/$TargetDir/ 2> /dev/null + cp -r $ThisDir/drivers_* $InstallDir/$TargetDir/ 2> /dev/null fi Refind="" CopyKeys @@ -184,7 +186,8 @@ CopyRefindFiles() { fi if [[ $InstallDrivers == 1 ]] ; then mkdir -p $InstallDir/$TargetDir/drivers_ia32 - cp -r $RefindDir/drivers_ia32/*_ia32.efi $InstallDir/$TargetDir/drivers_ia32/ + cp $RefindDir/drivers_ia32/*_ia32.efi $InstallDir/$TargetDir/drivers_ia32/ 2> /dev/null + cp $ThisDir/drivers_ia32/*_ia32.efi $InstallDir/$TargetDir/drivers_ia32/ 2> /dev/null fi Refind="refind_ia32.efi" elif [[ $Platform == 'EFI64' ]] ; then @@ -194,7 +197,8 @@ CopyRefindFiles() { fi if [[ $InstallDrivers == 1 ]] ; then mkdir -p $InstallDir/$TargetDir/drivers_x64 - cp -r $RefindDir/drivers_x64/*_x64.efi $InstallDir/$TargetDir/drivers_x64/ + cp $RefindDir/drivers_x64/*_x64.efi $InstallDir/$TargetDir/drivers_x64/ 2> /dev/null + cp $ThisDir/drivers_x64/*_x64.efi $InstallDir/$TargetDir/drivers_x64/ 2> /dev/null fi Refind="refind_x64.efi" CopyKeys @@ -448,14 +452,9 @@ GenerateKeys() { # appropriately. # Aborts script on error SignOneBinary() { - if [[ $UseSBSign == 1 ]] ; then - $SBSign --key $PrivateKey --cert $CertKey --output $2 $1 - if [[ $? != 0 ]] ; then - echo "Problem signing the binary $1! Aborting!" - exit 1 - fi - else - echo "PESign code not yet written; aborting!" + $SBSign --key $PrivateKey --cert $CertKey --output $2 $1 + if [[ $? != 0 ]] ; then + echo "Problem signing the binary $1! Aborting!" exit 1 fi } @@ -465,19 +464,22 @@ SignOneBinary() { # not, try to generate new keys and store them in $EtcKeysDir. ReSignBinaries() { SBSign=`which sbsign 2> /dev/null` + echo "Found sbsign at $SBSign" TempDir="/tmp/refind_local" if [[ ! -x $SBSign ]] ; then - echo "Can't find either sbsign or pesign; one of these is required to sign rEFInd" - echo "with your own keys! Aborting!" + echo "Can't find sbsign, which is required to sign rEFInd with your own keys!" + echo "Aborting!" exit 1 fi GenerateKeys mkdir -p $TempDir/drivers_x64 - cp $RefindDir/refind.conf-sample $TempDir + cp $RefindDir/refind.conf-sample $TempDir 2> /dev/null + cp $ThisDir/refind.conf-sample $TempDir 2> /dev/null cp $RefindDir/refind_ia32.efi $TempDir - cp -a $RefindDir/drivers_ia32 $TempDir - SignOneBinary $RefindDir/refind_x64.efi $TempDir/refind_x64.efi - for Driver in `ls $RefindDir/drivers_x64/*.efi` ; do + cp -a $RefindDir/drivers_ia32 $TempDir 2> /dev/null + cp -a $ThisDir/drivers_ia32 $TempDir 2> /dev/null + SignOneBinary $RefindDir/refind_x64.efi $ThisDir/refind_x64.efi + for Driver in `ls $RefindDir/drivers_x64/*.efi $ThisDir/drivers_x64/*.efi 2> /dev/null` ; do TempName=`basename $Driver` SignOneBinary $Driver $TempDir/drivers_x64/$TempName done diff --git a/mkdistrib b/mkdistrib index 2f894ed..e55521b 100755 --- a/mkdistrib +++ b/mkdistrib @@ -54,7 +54,7 @@ cd refind-$1 ARCH=ia32 make ARCH=ia32 make fs mkdir -p refind-bin-$1/refind/drivers_ia32 -cp --preserve=timestamps drivers/*_ia32.efi refind-bin-$1/refind/drivers_ia32/ +cp --preserve=timestamps drivers_ia32/*_ia32.efi refind-bin-$1/refind/drivers_ia32/ cp --preserve=timestamps filesystems/LICENSE*txt refind-bin-$1/refind/drivers_ia32/ cp refind/refind_ia32.efi refind-bin-$1/refind/refind_ia32.efi cp refind/refind_ia32.efi $StartDir/ @@ -63,12 +63,11 @@ cp refind/refind_ia32.efi $StartDir/ make clean make make fs -mkdir -p refind-bin-$1/refind/drivers +mkdir -p refind-bin-$1/refind/drivers_x64 cp -a icons refind-bin-$1/refind/ -for File in `ls drivers/*_x64.efi` ; do +for File in `ls drivers_x64/*_x64.efi` ; do $SBSign --key $KeysDir/refind.key --cert $KeysDir/refind.crt --output refind-bin-$1/refind/$File $File done -mv refind-bin-$1/refind/drivers refind-bin-$1/refind/drivers_x64 cp --preserve=timestamps filesystems/LICENSE*txt refind-bin-$1/refind/drivers_x64/ cp --preserve=timestamps refind.conf-sample refind-bin-$1/refind/ $SBSign --key $KeysDir/refind.key --cert $KeysDir/refind.crt --output refind-bin-$1/refind/refind_x64.efi refind/refind_x64.efi diff --git a/refind/main.c b/refind/main.c index e53c2ed..3ff6255 100644 --- a/refind/main.c +++ b/refind/main.c @@ -118,7 +118,7 @@ static VOID AboutrEFInd(VOID) if (AboutMenu.EntryCount == 0) { AboutMenu.TitleImage = BuiltinIcon(BUILTIN_ICON_FUNC_ABOUT); - AddMenuInfoLine(&AboutMenu, L"rEFInd Version 0.5.0.2"); + AddMenuInfoLine(&AboutMenu, L"rEFInd Version 0.5.0.3"); AddMenuInfoLine(&AboutMenu, L""); AddMenuInfoLine(&AboutMenu, L"Copyright (c) 2006-2010 Christoph Pfisterer"); AddMenuInfoLine(&AboutMenu, L"Copyright (c) 2012 Roderick W. Smith");