A recent commit moved where the shim_lock protocol is loaded and
unloaded, but did not move where exit was hooked and unhooked. Exit
needs to be hooked when the protocol is installed, so that the protocol
will be uninstalled on exit. Otherwise, the system can crash if, for
example, shim loads grub, the user exits grub, shim is run again, which
installs a second instance of the protocol, and then grub tries to use
the shim_lock protocol that was installed by the first instance of shim.
Signed-off-by: Stuart Hayes <stuart.w.hayes@gmail.com>
Upstream-commit-id: 06c92591e94
I have come across systems that are unwilling to reserve enough memory for
a MokListRT big enough for big certificates.
This seems to be the case with firmware implementations that do not support
secureboot, which is probably the reason they went with much lower variable
storage.
This patch set makes sure we can still boot on those systems, by only
making the copy action fatal if the system has secure boot enabled, or if
the error was anything other than EFI_INVALID_PARAMETER.
Signed-off-by: Patrick Uiterwijk <patrick@puiterwijk.org>
Upstream-commit-id: 741c61abba7
The shim_cert array was declared as a static array, and every user of
shim_cert.h would create a shim_cert array for its own and grow the file
size. To remove the unnecessary duplicate shim_cert arrays, this commit
declares shim_cert in shim.c while other users still can access the
array through the external variables: build_cert and build_cert_size.
Signed-off-by: Gary Lin <glin@suse.com>
Upstream-commit-id: 4e2d62f0f4e
The architecture is aarch64, not arch64.
Fixes: 750584c207 ("Make 64-on-32 maybe work on x86_64.")
Signed-off-by: dann frazier <dann.frazier@canonical.com>
Upstream-commit-id: e9f67aaa75a
The current code is incorrectly failing to load the fbaa64.efi image found
in Arm servers even though the UEFI shell code is able to properly load
and execute the same image.
The problem is due to the presence of a section header that has zero size
and address and marked "discardable" in the fbaa64.efi image.
Although there is already a check further down in the code to look for
the discardable bit and skip further verification checks if set, we never
get to that point due to the "end < base" check at the start of the loop.
Here is a dump of the fbaa64.efi image as compiled on an Arm machine
from the latest code in this repo:
% # First I used hexedit to change header byte from 'AA' to '86'
% # so that objdump was able to correctly parse the file:
% objdump -x -m aarch64 fbaa64.efi
fbaa64.efi: file format pei-x86-64
fbaa64.efi
architecture: i386:x86-64, flags 0x00000103:
HAS_RELOC, EXEC_P, D_PAGED
start address 0x0000000000000148
Characteristics 0x20e
executable
line numbers stripped
symbols stripped
debugging information removed
Time/Date Wed Dec 31 16:00:00 1969
Magic 020b (PE32+)
MajorLinkerVersion 2
MinorLinkerVersion 20
SizeOfCode 000b15d0
SizeOfInitializedData 00000000
SizeOfUninitializedData 00000000
AddressOfEntryPoint 0000000000000148
BaseOfCode 0000000000000148
ImageBase 0000000000000000
SectionAlignment 0000000000000020
FileAlignment 0000000000000008
MajorOSystemVersion 0
MinorOSystemVersion 0
MajorImageVersion 0
MinorImageVersion 0
MajorSubsystemVersion 0
MinorSubsystemVersion 0
Win32Version 00000000
SizeOfImage 000b1718
SizeOfHeaders 00000148
CheckSum 00000000
Subsystem 0000000a (EFI application)
DllCharacteristics 00000000
SizeOfStackReserve 0000000000000000
SizeOfStackCommit 0000000000000000
SizeOfHeapReserve 0000000000000000
SizeOfHeapCommit 0000000000000000
LoaderFlags 00000000
NumberOfRvaAndSizes 00000006
The Data Directory
Entry 0 0000000000000000 00000000 Export Directory [.edata (or where ever we found it)]
Entry 1 0000000000000000 00000000 Import Directory [parts of .idata]
Entry 2 0000000000000000 00000000 Resource Directory [.rsrc]
Entry 3 0000000000000000 00000000 Exception Directory [.pdata]
Entry 4 0000000000000000 00000000 Security Directory
Entry 5 0000000000000000 00000000 Base Relocation Directory [.reloc]
Entry 6 0000000000000000 00000000 Debug Directory
Entry 7 0000000000000000 00000000 Description Directory
Entry 8 0000000000000000 00000000 Special Directory
Entry 9 0000000000000000 00000000 Thread Storage Directory [.tls]
Entry a 0000000000000000 00000000 Load Configuration Directory
Entry b 0000000000000000 00000000 Bound Import Directory
Entry c 0000000000000000 00000000 Import Address Table Directory
Entry d 0000000000000000 00000000 Delay Import Directory
Entry e 0000000000000000 00000000 CLR Runtime Header
Entry f 0000000000000000 00000000 Reserved
Sections:
Idx Name Size VMA LMA File off Algn
0 .reloc 00000000 0000000000000000 0000000000000000 00000000 2**0
ALLOC, LOAD, READONLY, DATA
1 .text 000b15d0 0000000000000148 0000000000000148 00000148 2**4
CONTENTS, ALLOC, LOAD, CODE
SYMBOL TABLE:
no symbols
Signed-off-by: Maran Wilson <maran.wilson@oracle.com>
Reviewed-by: Aaron Young <aaron.young@oracle.com>
Reviewed-by: Jack Schwartz <jack.schwartz@oracle.com>
Upstream-commit-id: 6df7a8f5609
When shim is invoked from a relative path (e.g: from the UEFI shell), the
Loaded Image handle LoadOptions can be set to the binary relative path.
But the is_our_path() function only checks if LoadOptions is set to the
absolute path of shim to ignore it. So if a relative path is there, shim
would set itself as the secondary loader and invoke itself in a loop.
To prevent that, use the path in LoadOptions to calculate the absolute
path and compare it with the one in the Loader Image handle FilePath.
Resolves: bz#1622485
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Maran Wilson maran.wilson@oracle.com
Tested-by: Maran Wilson maran.wilson@oracle.com
Upstream-commit-id: e563bc3dcd1
The generate_path_from_image_path() doesn't properly handle the case when
shim is invoked using a relative path (e.g: from the EFI shell). In that
function, always the last component is stripped from absolute file path
to calculate the dirname, and this is concatenated with the image path.
But if the path is a relative one, the function will wrongly concatenate
the dirname with the relative image path, i.e:
Shell> FS0:
FS0:\> cd EFI
FS0:\EFI\> BOOT\BOOTX64.EFI
Failed to open \EFI\BOOT\BOOT\BOOTX64.EFI - Not found
Failed to load image \EFI\BOOT\BOOT\BOOTX64.EFI: Not found
start_image() returned Not found
Calculate the image path basename and concatenate that with the dirname.
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Maran Wilson maran.wilson@oracle.com
Tested-by: Maran Wilson maran.wilson@oracle.com
Upstream-commit-id: a625fa5096c
Knowing the value of the reloc directory size is helpful for debugging,
cf. issue #131 [1],
[1]: https://github.com/rhboot/shim/issues/131
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Upstream-commit-id: dd3230d07f3
This was merged before it was really ready - verify_trusted_cert needs
to check each certificate against vendor_dbx, "dbx", and "MokListX", or
else it can enable a blacklisted certificate accidentally.
This reverts commit 8721bbe6fb.
Allow shim to perform verification against a list of trusted
certificates by simply concatenating the DER files.
Signed-off-by: Michael Brown <mbrown@fensystems.co.uk>
There is currently no way for a caller of handle_image() to free the
memory allocated to hold the relocated executable. Fix by adding the
allocated memory address and number of pages as returned parameters
from handle_image().
Signed-off-by: Michael Brown <mbrown@fensystems.co.uk>
Treat entry_point as a returned parameter from handle_image(), rather
than using a global variable.
Signed-off-by: Michael Brown <mbrown@fensystems.co.uk>
relocate_coff() currently modifies the PE header within the raw data.
This appears to be unnecessary, and causes a verification failure if a
second attempt is made to verify the same data buffer.
Signed-off-by: Michael Brown <mbrown@fensystems.co.uk>
Remove the setup_console(1) calls from shim and instead make lib/console.c
make that call when necessary. This avoids shim forcing the EFI console to
switch to text-mode if nothing is printed.
This commit also modifies MokManager to work the same way for consistency,
even though MokManager will always print something.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
This is a preparation commit for removing the setup_console(1) calls from
MokManager and shim so that we don't force the EFI console to switch to
text-mode.
This commit replaces all direct calls to Print / PrintAt with calls to
the new helpers (no functional changes) so that we can delay calling
setup_console(1) till the first Print call in a follow-up patch.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
When the firmware is using EFI_LOAD_OPTION to specify options for the secondary
loader, the shim will properly detect that and return in set_second_stage. Later
howerer in handle_image EFI_LOADED_IMAGE is being overwritten with load_option
irrespective of the fact that load_option was never set. This effectively
prevents the EFI_LOAD_OPTION from reaching the secondary loader.
Only overwrite EFI_LOADED_IMAGE's LoadOptions when load_option is not NULL
solves the problem.
Signed-off-by: Tamas K Lengyel <lengyelt@ainfosec.com>
This makes it so shim's idea of Mok variables all resides in one table
of data, and we don't need a bunch of nearly identical ad-hoc functions
to handle each of them.
Signed-off-by: Peter Jones <pjones@redhat.com>
clang-analyzer thinks that because we're not checking for NULL from
ImageAddress() it can be NULL, but doesn't realize we've already checked
that value once before.
Check it again, it can't hurt.
Signed-off-by: Peter Jones <pjones@redhat.com>
Clang believes "SumOfBytesHashed" is never used, because the thing that
uses that computed value is #if 0'd currently.
Just swizzle the #if's so that line is also not compiled.
Signed-off-by: Peter Jones <pjones@redhat.com>
I'm pretty done with typing uefi_call_wrapper() and counting arguments
every time. Instead, just make the compiler error if we don't have
ms_abi. Also, make it so nothing can use uefi_call_wrapper() directly.
Signed-off-by: Peter Jones <pjones@redhat.com>
Also consistently name our status variable "efi_status" unless there's a
good reason not to, such as already having another one of those.
Signed-off-by: Peter Jones <pjones@redhat.com>
"FixupData" in the edk2 tree is a log of the relocations that happened,
which is allocated by the "client" calling relocate, and written into
while it does relocations. Since we never allocate that log anywhere,
FixupData is always NULL, and so covscan says:
318 case EFI_IMAGE_REL_BASED_HIGH:
319 Fixup16 = (UINT16 *) Fixup;
320 *Fixup16 = (UINT16) (*Fixup16 + ((UINT16) ((UINT32) Adjust >> 16)));
null: At condition FixupData != NULL, the value of FixupData must be
NULL. dead_error_condition: The condition FixupData != NULL cannot
be true.
321 if (FixupData != NULL) {
CID 182859 (#1 of 4): Logically dead code (DEADCODE)dead_error_begin:
Execution cannot reach this statement: *((UINT16 *)FixupData) =
*F....
322 *(UINT16 *) FixupData = *Fixup16;
323 FixupData = FixupData + sizeof (UINT16);
324 }
325 break;
And it's right; all four occurrances are deadcode that never do anything
but confuse the reader.
Kill it with fire.
Signed-off-by: Peter Jones <pjones@redhat.com>
Covscan noticed:
746static EFI_STATUS generate_hash (char *data, unsigned int datasize_in,
747 PE_COFF_LOADER_IMAGE_CONTEXT *context,
748 UINT8 *sha256hash, UINT8 *sha1hash)
749
750{
...
764
CID 182849 (#1 of 1): Unsigned compared against 0
(NO_EFFECT)unsigned_compare: This less-than-zero comparison of an
unsigned value is never true. datasize_in < 0U.
765 if (datasize_in < 0) {
766 perror(L"Invalid data size\n");
767 return EFI_INVALID_PARAMETER;
768 }
And I guess that's a fair point, but some of the callers take the size
as a signed integer. So we should be handling that on all the input
cases instead of getting that far.
Signed-off-by: Peter Jones <pjones@redhat.com>
This commit fixes 2 issues with the TPM support code:
1) Remove "REQUIRE_TPM ?=" line from the Makefile, further down the Makefile
checks if REQUIRE_TPM is undefined, but the above line sets it to an empty
string, which is not the same as undefined. Without this handle_image fails
after the tpm_log_pe() call even if REQUIRE_TPM=1 once was not set when
building the shim
2) When secure-boot is disabled then shim_verify() would exit with the
status of tpm_log_pe(), which on systems with a TPM is an error. Combined
with the recent change to always install the shim protocols, this causes
grub to refuse to boot any kernel since the verify() call now always fails.
This commit fixes this by explicitly setting status = EFI_SUCCESS when
secure-boot is disabled.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Currently the shim_lock protocol is only installed when SecureBoot is enabled.
However, having Verify just measure into the TPM without SecureBoot is a useful
feature.
Signed-off-by: Tamas K Lengyel <lengyelt@ainfosec.com>
Currently the only measurement the shim logs in the TPM is that of the EFI
application it directly loads. However, there are no measurements being taken
of application that are being verified through the shim_lock protocol. In this
patch we extend PCR4 for any binary for which Verify is being called through
the shim_lock protocol.
Signed-off-by: Tamas K Lengyel <lengyelt@ainfosec.com>
Make sure if we chainload things, a chainloaded bootloader will be able to use
the latest systab replacements and protocols. They need to match for things
to validate correctly.
Signed-off-by: Mathieu Trudel-Lapierre <mathieu.trudel-lapierre@canonical.com>
