With this change, the embedded certificate and dbx lists (vendor_cert,
vendor_cert_size, vendor_dbx, and vendor_dbx_size) wind up being in a
section named .vendor_cert, and so will look something like:
------
fenchurch:~/devel/github.com/shim$ objdump -h shim.efi
shim.efi: file format pei-x86-64
Sections:
Idx Name Size VMA LMA File off Algn
0 .eh_frame 000174a8 0000000000005000 0000000000005000 00000400 2**3
CONTENTS, ALLOC, LOAD, READONLY, DATA
1 .text 000aa7e1 000000000001d000 000000000001d000 00017a00 2**4
CONTENTS, ALLOC, LOAD, READONLY, CODE
2 .reloc 0000000a 00000000000c8000 00000000000c8000 000c2200 2**0
CONTENTS, ALLOC, LOAD, READONLY, DATA
3 .data 00031228 00000000000c9000 00000000000c9000 000c2400 2**5
CONTENTS, ALLOC, LOAD, DATA
4 .vendor_cert 00000375 00000000000fb000 00000000000fb000 000f3800 2**0
CONTENTS, READONLY
5 .dynamic 000000f0 00000000000fc000 00000000000fc000 000f3c00 2**3
CONTENTS, ALLOC, LOAD, DATA
6 .rela 0002afa8 00000000000fd000 00000000000fd000 000f3e00 2**3
CONTENTS, ALLOC, LOAD, READONLY, DATA
7 .dynsym 0000f1f8 0000000000128000 0000000000128000 0011ee00 2**3
CONTENTS, ALLOC, LOAD, READONLY, DATA
------
This simplifies a security audit, because it means that different
versions of shim with substantially the same code with different keys
will be more easily comperable, and therefore logic differences may be
more easily identified.
This also means that if there's a trusted build you want to use, you can
remove the certificates, implant new ones, and have it signed, and the
code sections won't change.
Signed-off-by: Peter Jones <pjones@redhat.com>
GCC 4.8.0 will try to use these by default, and you'll wind up looping
across the (uninitialized!) trap handler for uninitialized instructions.
Signed-off-by: Peter Jones <pjones@redhat.com>
I'm told rebooting is sometimes unreliable when called here, and we'll
get bootx64.efi loaded anyway. I'll just assume that's true and try to
load the first option, since it's clearly what we'd prefer happens next.
Signed-off-by: Peter Jones <pjones@redhat.com>
If shim is invoked as \EFI\BOOT\BOOT*.EFI and a file exists named
\EFI\BOOT\FALLBACK.EFI, try it instead of our second stage. So don't
put fallback.efi on your install media in \EFI\BOOT, because that won't
do whatever it is you're hoping for, unless you're hoping not to start
the installer.
So here's the process for using this:
in /EFI/fedora/ (or whichever directory you happen to own), you put:
shim.efi
grub.efi
boot.csv - format is: shim.efi,Nice Label,cmdline arguments,comments
- filenames refer only to files in this directory, with no
leading characters such as L"./" or L"/EFI/fedora/"
- note that while this is CSV, the character encoding is
UCS-2
and if /EFI/BOOT/BOOTX64.EFI doesn't already exist, then in /EFI/BOOT:
shim.efi as BOOTX64.EFI
fallback.efi
Signed-off-by: Peter Jones <pjones@redhat.com>
The previous commit, 14d4b8e, caused shim failed to parse the name
of the 2nd stage loader in UEFI shell. Amend parsing of the name the
2nd stage loader to be compatible with UEFI shell.
To create an boot entry for elilo.efi:
# efibootmgr -c -L "shim elilo" -l "efi\\shim.efi" -u "shim.efi elilo.efi"
Sometimes when we're creating paths, the ImagePath can contain the
directory name already. If that happens, don't add it in again.
Signed-off-by: Peter Jones <pjones@redhat.com>
If li->LoadOptions tells us to execute our own binary, it's clearly not
what we want to do for the second stage. So simply ignore that case.
Signed-off-by: Peter Jones <pjones@redhat.com>
Since Pause() doesn't clear the key from the input queue, the next
ReadKeyStroke reads the queued key instead of the new one. If the
user presses "Enter", MokManager exits directly without showing
the menu again.
This commit replaces the 2nd stage loader path with the first
argument in the Load Options and moves the rest arguments (if any)
to the Load Options for the 2nd stage loader.
For example, to make shim to load elilo.efi, just create a new
boot entry with efibootmgr:
# efibootmgr -c -L "shim elilo" -l "efi\\shim.efi" -u "elilo.efi"
shim needs to verify that MokManager hasn't been modified, but we want to
be able to support configurations where shim is shipped without a vendor
certificate. This patch adds support for generating a certificate at build
time, incorporating the public half into shim and signing MokManager with
the private half. It uses pesign and nss, but still requires openssl for
key generation. Anyone using sbsign will need to figure this out for
themselves.
Cert needs to be modified inside the Index loop, not outside it. This is unlikely to
ever trigger since there will typically only be one X509 certificate per
EFI_SIGNATURE_LIST, but fix it anyway.
