Woops. The net outcome of these is going to be a sleep of unknown
duration, followed by either a) ResetSystem() with some random selection
of warm/cold boot, or b) ResetSystem() returning an error and shim
returning error from efi_main().
Signed-off-by: Peter Jones <pjones@redhat.com>
Right now applications run by shim get our wrapper for Exit(), but it
doesn't do as much cleanup as it should - shim itself also exits, but
currently is not doing all the cleanup it should be doing.
This changes it so all of shim's cleanup is also performed.
Based on a patch and lots of review from Gary Lin.
Signed-off-by: Peter Jones <pjones@redhat.com>
Right now if shim_verify() sees secure_mode()==0, it exits with
EFI_SUCCESS, but accidentally leaves in_protocol=1. This means any
other call will have supressed error/warning messages.
That's wrong, so don't do it.
Signed-off-by: Peter Jones <pjones@redhat.com>
Don't run MokManager on any random error from start_image(second_stage);
only try it if it /is/ the second stage, or if start_image gave us
EFI_SECURITY_VIOLATION.
Signed-off-by: Peter Jones <pjones@redhat.com>
System services haven't been hooked if we're not in secure mode, so
do_exit() will never be called. In this case shim never gets control
once grub exits, which means if booting fails and the firmware tries
another boot option, it'll attempt to talk to the shim protocol we
installed.
This is wrong, because it is allowed to have been cleared from ram at
this time, since the task it's under has exited.
So just don't install the protocols when we're not enforcing.
This version also has a message and a 2-second stall after calling
start_image(), so that we can tell if we are on the expected return path
of our execution flow.
Turns out a) the codegen on aarch64 generates code that has real
alignment needs, and b) if we check the length of discardable sections
before discarding them, we error for no reason.
So do the error checking in the right order, and always enforce some
alignment because we know we have to.
Signed-off-by: Peter Jones <pjones@redhat.com>
We replaced the build key with an empty file while compiling shim
for our distro. Skip the verification with the empty build key
since this makes no sense.
Signed-off-by: Gary Ching-Pang Lin <glin@suse.com>
Find the relocations based on the *file* address in the old binary,
because it's only the same as the virtual address some of the time.
Also perform some extra validation before processing it, and don't bail
out in /error/ if both ReloceBase and RelocEnd are null - that condition
is fine.
Signed-off-by: Peter Jones <pjones@redhat.com>
When I merged 4bfb13d and fixed the conflicts, I managed to make the
in_protocol test exactly backwards, so that's why we don't currently see
error messages.
Signed-off-by: Peter Jones <pjones@redhat.com>
Actually check the size of our vendor cert quite early, so that there's
no confusion as to what's going on.
This isn't strictly necessary, in that in all cases if vendor_cert_size
is 0, then AuthenticodeVerify -> Pkcs7Verify() -> d2i_X509() will result
in a NULL "Cert", and it will return FALSE, and we'll reject the
signature, but better to avoid all that code in the first place. Belt
and suspenders and whatnot.
Based on a patch from https://github.com/TBOpen .
Signed-off-by: Peter Jones <pjones@redhat.com>
I screwed one of these up when working on 750584c, and it's a real pain
to figure out, so that means we should be validating them.
Signed-off-by: Peter Jones <pjones@redhat.com>
This is mostly based on a patch (https://github.com/mjg59/shim/issues/30)
from https://github.com/TBOpen , which refactors our __LP64__
tests to be tests of the header magic instead. I've simplified things
by using what we've pre-loaded into "context" and making some helper
functions so the conditionals in most of the code say what they do,
instead of how they work.
Note that we're only allowing that from in_protocol's loader - that is,
we'll let 64-bit grub load a 32-bit kernel or 32-bit grub load a 64-bit
kernel, but 32-bit shim isn't loading a 64-bit grub.
Signed-off-by: Peter Jones <pjones@redhat.com>
Currently when we process base relocations, we get the correct Data
Directory pointer from the headers (context->RelocDir), and that header
has been copied into our pristine allocated image when we copied up to
SizeOfHeaders. But the data it points to has not been mirrored in to
the new image, so it is whatever data AllocPool() gave us.
This patch changes relocate_coff() to refer to the base relocation table
from the image we loaded from disk, but apply the fixups to the new
copy.
I have no idea how x86_64 worked without this, but I can't make aarch64
work without it. I also don't know how Ard or Leif have seen aarch64
work. Maybe they haven't? Leif indicated on irc that they may have
only tested shim with simple "hello world" applications from gnu-efi;
they are certainly much less complex than grub.efi, and are generated
through a different linking process.
My only theory is that we're getting recycled data there pretty reliably
that just makes us /not/ process any relocations, but since our
ImageBase is 0, and I don't think we ever load grub with 0 as its base
virtual address, that doesn't follow. I'm open to any other ideas
anybody has.
I do know that on x86_64 (and presumably aarch64 as well), we don't
actually start seeing *symptoms* of this bug until the first chunk[0] of
94c9a77f is applied[1]. Once that is applied, relocate_coff() starts
seeing zero[2] for both RelocBase->VirtualAddress and
RelocBase->SizeOfBlock, because RelocBase is a (generated, relative)
pointer that only makes sense in the context of the original binary, not
our partial copy. Since RelocBase->SizeOfBlock is tested first,
relocate_base() gives us "Reloc block size is invalid"[3] and returns
EFI_UNSUPPORTED. At that point shim exits with an error.
[0] The second chunk of 94c9a77f patch makes no difference on this
issue.
[1] I don't see why at all.
[2] Which could really be any value since it's AllocatePool() and not
AllocateZeroPool() results, but 0 is all I've observed; I think
AllocatePool() has simply never recycled any memory in my test
cases.
[3] which is silent because perror() tries to avoid talking because that
has caused much crashing in the past; work needs to go in to 0.9 for
this.
Signed-off-by: Peter Jones <pjones@redhat.com>
Since in theory you could, for example, get an x86_64 binary signed that
also behaves as an ARM executable, we should be checking this before
people build on other architectures.
Signed-off-by: Peter Jones <pjones@redhat.com>
On archs where no EFI aware objcopy is available, the generated PE/COFF
header contains a .reloc section which is completely empty. Handle this by
- returning early from relocate_coff() with EFI_SUCCESS,
- ignoring discardable sections in the section loader.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
MokSBState and MokDBState are just 1 byte variables, so a UINT8
local variable is sufficient to include the content.
Signed-off-by: Gary Ching-Pang Lin <glin@suse.com>
Conflicts:
shim.c
There are functions defined in lib to check the secure variables.
Use the functions to shun the duplicate code.
Signed-off-by: Gary Ching-Pang Lin <glin@suse.com>
Conflicts:
shim.c
When grub2 invokes the functions of shim protocol in gfx mode,
OutputString in shim could distort the screen.
Signed-off-by: Gary Ching-Pang Lin <glin@suse.com>
Conflicts:
shim.c
(modified by pjones to include some newer Prints that weren't there when
Gary did the initial work here.)
A non-DER encoding x509 certificate may be mistakenly enrolled into
db or MokList. This commit checks the first 4 bytes of the certificate
to ensure that it's DER encoding.
This commit also removes the iteration of the x509 signature list.
Per UEFI SPEC, each x509 signature list contains only one x509 certificate.
Besides, the size of certificate is incorrect. The size of the header must
be substracted from the signature size.
Signed-off-by: Gary Ching-Pang Lin <glin@suse.com>
The previous strategy is to locate the first available PXE_BASE_CODE
protocol and to fetch the second stage image from it, and this may
cause shim to fetch the wrong second stage image, i.e. grub.efi.
Consider the machine with the following boot order:
1. PXE Boot
2. Hard Drive
Assume that the EFI image, e.g. bootx64.efi, in the PXE server is
broken, then "PXE Boot" will fail and fallback to "Hard Drive". While
shim.efi in "Hard Drive" is loaded, it will find the PXE protocol is
available and fetch grub.efi from the PXE server, not grub.efi in the
disk.
This commit checks the DeviceHandle from Loaded Image. If the device
supports PXE, then shim fetches grub.efi with the PXE protocol. Otherwise,
shim loads grub.efi from the disk.
Signed-off-by: Gary Ching-Pang Lin <glin@suse.com>
In read_header, we adjust context->PEHdr's address by doshdr->e_lfanew.
If we're going to recompute that address, we have to adjust it here
too.
Signed-off-by: Peter Jones <pjones@redhat.com>
This adds additional bounds-checking on the section sizes. Also adds
-Wsign-compare to the Makefile and replaces some signed variables with
unsigned counteparts for robustness.
Signed-off-by: Kees Cook <kees@ubuntu.com>
Track use of the system's LoadImage(), and when the next StartImage()
call is for an image the system verified, allow that to count as
participating, since it has been verified by the system's db.
Signed-off-by: Peter Jones <pjones@redhat.com>
Shim should only need to enforce its security policy when its launching
binaries signed with its built-in key. Binaries signed by keys in db or
Mokdb should be able to rely on their own security policy.
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
insecure_mode was intended to indicate that the user had explicity disabled
checks with mokutil, which means it wasn't the opposite of secure_mode().
Change the names to clarify this and don't show the insecure mode message
unless the user has explicitly enabled that mode.
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
%r when used in Print() will show a string representation of
an EFI_STATUS code.
Change-Id: I6db47f5213454603bd66177aca378ad01e9f0bd4
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
() Fix the return value semantics. If the MokList doesn't
exist, we are OK. If the MokList was compromised but we
were able to erase it, that is OK too. Only if the list
can't be nuked do we return an error.
() Fix use of potentially uninitialized attribute variable
() Actually use the return value when called from verify_buffer.
Change-Id: If16df21d79c52a1726928df96d133390cde4cb7e
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
After going back and inspecting this further, the logic for "SetupMode"
being present at all was incorrect. Also initialize our state earlier
so it's sure to always be set.
Signed-off-by: Peter Jones <pjones@redhat.com>
When we call hook_system_services(), we're currently only checking mok's
setting. We should use secure_mode() instead so it'll check both.
Signed-off-by: Peter Jones <pjones@redhat.com>
This reverts commit 21e40f0174.
In principle I like the idea of what's going on here, but
generate_hash() really does need to have the expected result.
If a binary isn't signed, but its hash is enrolled in db, it won't have
a certificate database. So in those cases, don't check it against
certificate databases in db/dbx/etc, but we don't need to reject it
outright.
Signed-off-by: Peter Jones <pjones@redhat.com>
This adds additional bounds-checking on the section sizes. Also adds
-Wsign-compare to the Makefile and replaces some signed variables with
unsigned counteparts for robustness.
Signed-off-by: Kees Cook <kees@ubuntu.com>
Provide a mechanism for a physically present end user to disable the use
of db when doing signature verification. This is handled by the OS passing
down a variable that contains a UINT32 and a SHA256 hash. If this variable
is present, MokManager prompts the user to choose whether to enable or
disable the use of db for verification purposes (depending on the value of
the UINT32). They are then asked to type the passphrase that matches the
hash. This then saves a boot services variable which is checked by shim,
and if set will cause shim to not use db for verification purposes. If
db is to be ignored, shim will export a runtime variable called
'MokIgnoreDB' for the OS to query at runtime.
Signed-off-by: Josh Boyer <jwboyer@fedoraproject.org>
This shouldn't be exploitable unless you've got a way to make
InstallProtocol fail and still, for example, have memory free to
actually load and run something.
Signed-off-by: Peter Jones <pjones@redhat.com>
It works like this: during startup of shim, we hook into the system's
ExitBootServices() and StartImage(). If the system's StartImage() is
called, we automatically unhook, because we're chainloading to something
the system can verify.
When shim's verify is called, we record what kind of certificate the
image was verified against. If the call /succeeds/, we remove our
hooks.
If ExitBootServices() is called, we check how the bootloader verified
whatever it is loading. If it was verified by its hash, we unhook
everything and call the system's EBS(). If it was verified by
certificate, we check if it has called shim_verify(). If it has, we
unhook everything and call the system's EBS()
If the bootloader has not verified anything, and is itself verified by
a certificate, we display a security violation warning and halt the
machine.
This moves them both to be computed at runtime from a pointer+offset
rather than just a pointer, so that their real address can be entirely
derived from the section they're in.
This means you can replace the whole .vendor_cert section with a new one
with certs that don't have the same size.
- The file path from DevicePathToStr may use slash as the file
seperator. Change all slashes to backslashes to avoid the strange
bootpath.
- Remove the redundant backslashes.
- ImagePath no longer requires the leading backslash.
- Fix a memory leak
Based on the patch from Michal Marek <mmarek@suse.com>
A wrong pointer was being passed to EFI_PXE_BASE_CODE_TFTP_READ_FILE,
preventing us from getting the file size back from the tftp call, ensuring
that we don't have enough information to properly secureboot-validate the
retrieved image.
Right now the CA is checking if shim builds expose a particular version
of the shim protocol. To do this, they're looking for SHIM_LOCK_GUID's
value in the resulting binary.
Currently, with SHIM_LOCK_GUID as a macro that gets assigned to local
variables, that means they have to compensate for mov instructions mixed
in with the actual value. This is completely absurd, so promote it to a
first-class object with a symbol to make it both easy to find and
continuous.
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>
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.
