Citation :
Replacing Your Firmware's Keys
It's possible to replace Microsoft's keys with your own. This can be a useful approach if you want the benefits of Secure Boot but don't want to trust Microsoft or any of the others who will be signing binaries with the Microsoft keys. There are three main steps to this process: generating your own keys, signing your binaries, and installing your keys in your firmware. I describe each of these steps in turn. Be aware that, at least as of late 2012, the procedures required to add your own keys are fairly advanced. For instance, I describe how to obtain the necessary Linux software via git and to compile it locally. If you're not comfortable with such procedures, you may have to abandon this approach.
Generating Your Own Keys
The first step to using your own Secure Boot keys is to generate these keys. To do so, you must first install two programs, neither of which is yet widely available in binary form. The first of these programs is efitools and the second is sbsigntool (the same program used to sign MOKs). Both programs rely on the GNU-EFI library. The procedure for installing all of these packages is as follows:
Go to the GNU-EFI Web site and download version 3.0r of the package (gnu-efi_3.0r.orig.tar.gz). Officially, version 3.0q or later is required; however, I've found that version 3.0s produces binaries that don't work. Perhaps this problem will be fixed in future versions of GNU-EFI or of the programs that build against it.
Unpack gnu-efi_3.0r.orig.tar.gz, cd into the resulting directory, type make to build the package, and then type make install as root to install it.
Change to your home directory or some other convenient location, such as /usr/src, and type git clone git://kernel.ubuntu.com/jk/sbsigntool. This step will succeed only if the git program is installed, so you may need to install it. Alternatively, you can download and install a binary package from the OpenSUSE Build Service and skip ahead to step #10.
Change into the sbsigntool directory that results and type ./autogen.sh. This step retrieves additional source code into the sbsigntool directory tree. (If you get error messages about various programs, including automake, not being found, you must install the automake package and repeat this step.)
Edit the configure script and change every instance of the string /usr/include/efi to /usr/local/include/efi. (You should omit this step if you installed GNU-EFI so that its include files reside in /usr/include/efi.)
Type ./configure to configure the package. If this produces error messages about missing development packages, you must install them and repeat this step until it succeeds.
Type make to build the package.
As root, type make install to install the sbsigntool programs.
Back out of the sbsigntool directory (to your home directory or /usr/src, for example).
Type git clone git://git.kernel.org/pub/scm/linux/kernel/git/jejb/efitools.git. This action produces a directory called efitools containing additional source code.
Change into the efitools directory.
Open the Make.rules file in a text editor and replace every instance of /usr/include/efi with /usr/local/include/efi. (They're all on the INCDIR line early in the file.) While still editing this file, change every instance of /usr/lib64 to /usr/local/lib. Note both the inclusion of the local subdirectory and the change from lib64 to lib. (This change won't be necessary, or a variant of it may be needed, if you installed GNU-EFI from a binary package.)
Type make. The result should be a number of files and programs, most notably including LockDown.efi, which installs keys that were generated during the build process.
Back out of the efitools directory.
Copy the entire efitools directory to a medium that you can read on your target computer. This could be the EFI System Partition (ESP) on the computer you used to build the files or a FAT partition on a USB flash drive, for instance.
At this point, you have Secure Boot keys in files within the efitools directory, and the LockDown.efi program will install them once you run it from an EFI shell program under the right circumstances. Of course, there's no point to locking down the firmware unless you have a signed boot loader, so that's the next step....
Signing Your Binaries
You'll presumably want to sign binaries such as grub.efi or a Linux kernel with an EFI stub loader. Furthermore, if you're planning to dual-boot with Windows or some other OS, you'll probably have to sign its boot loader, too. This is true even if it's already been signed with another key—the procedure described on this page replaces your firmware's existing keys, so existing signatures will no longer work, and you must therefore replace the signatures on existing binaries.
In any event, the procedure to sign an EFI binary is fairly straightforward, once you've installed the sbtools package and created keys by preparing the efitools package:
$ sbsign --key ~/efitools/DB.key --cert ~/efitools/DB.crt \
--output vmlinuz-signed.efi vmlinuz.efi
warning: file-aligned section .text extends beyond end of file
warning: checksum areas are greater than image size. Invalid section table? |
This example signs the vmlinuz.efi binary, located in the current directory, writing the signed binary to vmlinuz-signed.efi. Of course, you must change the names of the binaries to suit your needs, as well as adjust the path to the keys (DB.key and DB.crt).
This example shows two warnings. I don't claim to fully understand them, but they don't seem to do any harm—at least, the Linux kernel binaries I've signed that have produced these warnings have worked fine. Another warning I've seen on binaries produced with GNU-EFI also seems harmless:
warning: data remaining[1231832 vs 1357089]: gaps between PE/COFF sections? |
On the other hand, the ChangeLog file for GNU-EFI indicates that binaries created with GNU-EFI versions earlier than 3.0q may not boot in a Secure Boot environment when signed, and signing such binaries produces another warning:
warning: gap in section table:
.text : 0x00000400 - 0x00019c00,
.reloc : 0x00019c91 - 0x0001a091,
warning: gap in section table:
.reloc : 0x00019c91 - 0x0001a091,
.data : 0x0001a000 - 0x00035000,
gaps in the section table may result in different checksums |
If you see a warning like this, you may need to rebuild your binary using a more recent version of GNU-EFI.
If you're using rEFIt, rEFInd, or gummiboot, you must sign not just those boot manager binaries, but also the boot loaders that they launch, such as Linux kernels or ELILO binaries. If you fail to do this, you'll be unable to launch the boot loaders that the boot managers are intended to launch. Stock versions of ELILO and GRUB don't check Secure Boot status or use EFI system calls to load kernels, so even signed versions of these programs will launch any kernel you feed them. This defeats the purpose of Secure Boot, though, at least when launching Linux. At least some future versions of GRUB will communicate with shim for authenticating Linux kernels and so may refuse to launch a Linux kernel that's not been signed.
Once you've signed your binaries, you should install them to your ESP as you would an unsigned EFI binary. Signed binaries should work fine even on systems on which you've disabled Secure Boot.
As a side note, the pesign utility, available from git://github.com/vathpela/pesign.git, is an alternative to sbtools; however, because efitools is coded to use sbtools, I've barely looked at pesign. You might want to check it out if you have problems with sbtools, though.
Installing Your Own Keys
With your keys ready and your binaries signed, you can now configure your computer to use them. Unfortunately, this process is likely to vary greatly from one EFI implementation to another. The following is based on my experiences with an ASUS P8H77-I motherboard, so if you're using a different EFI implementation, you may need to look for options that are similar but not identical to those described here, or even deviate very substantially from the following instructions. With that caveat out of the way, here's how to install Secure Boot keys on at least some computers:
Prepare an EFI-bootable medium that contains an EFI shell. You could install the EFI shell as EFI/BOOT/bootx64.efi or set it up so that it can be launched from the EFI's own boot manager or from rEFInd or gummiboot. Test to be sure you can enter this shell. (If Secure Boot is already enabled, you'll need to disable it first.)
Enter the computer's firmware utility by pressing Del during the initial stages of the boot process (before any boot loader appears). Some computers use other keys for this purpose; examine your early boot-time messages or read your computer's manual to learn what to use.
If you're configured to boot in EZ Mode, press F7 to enter Advanced Mode.
Click the Boot tab.
Click Security Boot Parameters near the bottom-left of the screen. (It's conceivable you'll need to scroll down to see this on some systems.)
For OS Type, select Windows 8 UEFI. (Yes, even if you're not going to boot Windows.)
For Secure Boot Mode, select Custom. The screen should look something like this:
Click Key Management to get to the page in which you can manage keys, as shown here:
Set Default Key Provisioning to Disable.
Click Clear Secure Boot Keys to remove any old keys.
If you placed the efitools directory on a USB flash disk, insert it into the computer.
Press F10 to save your changes and reboot the computer.
If necessary, as the computer starts up, press F8 to enter the firmware's boot manager to select the medium you prepared to boot the EFI shell. (F8 is the key that ASUS uses in the P8H77-I to load the boot manager; this key may be different on other computers.)
Launch your EFI shell.
Change to the filesystem holding efitools and enter that directory. For instance, you might type fs4: followed by cd efitools.
Type LockDown.efi to enter your keys into the firmware and enable Secure Boot mode. If you receive a message to the effect that the computer is not in Setup mode, then you should review the last few steps; or if you're using firmware other than ASUS', you may need to experiment to learn how to kick your system into Setup mode. Alternatively, you could try loading your various keys manually using the various Set ... from File options in the user interface.
At this point, your computer should be set up for Secure Boot. (If you haven't already installed your signed EFI binaries, though, you must do so now.) You should be able to reboot and use the signed binaries; but unsigned binaries, or those signed by anybody but you, should not run.
|
![[:dje69r:3]](https://forum-images.hardware.fr/images/perso/3/dje69r.gif "[:dje69r:3]")
![[:prozac]](https://forum-images.hardware.fr/images/perso/prozac.gif "[:prozac]")
![[:stockholm]](https://forum-images.hardware.fr/images/perso/stockholm.gif "[:stockholm]")
![[:jesus_consteration]](https://forum-images.hardware.fr/images/perso/jesus_consteration.gif "[:jesus_consteration]")
![[:black_jack]](https://forum-images.hardware.fr/images/perso/black_jack.gif "[:black_jack]")
![[:benn25]](https://forum-images.hardware.fr/images/perso/benn25.gif "[:benn25]")
![[:michelnet1]](https://forum-images.hardware.fr/images/perso/michelnet1.gif "[:michelnet1]")
![[:lehman brothers]](https://forum-images.hardware.fr/images/perso/lehman brothers.gif "[:lehman brothers]")
, ou bien signer votre kernel "stubbé" ) 
