| Age | Commit message (Collapse) | Author |
|---|
|
If the LoadOptions string count is zero, then it's assumed that it is an
EFI_LOAD_OPTION and the OptionalData field attempt to be parsed. If that
fails as well, in the second stage was set to the default loader path.
But this behaviour was changed by the commit 018b74d2 ("shim: attempt to
improve the argument handling"), and not in that case the LoadOptions is
attempted to be used as a single string. This breaks some firmwares that
return something in the LoadOptions but are not a proper EFI device path.
Instead of making assumptions about the LoadOptions if can't be parsed
correctly, just use the default loader as it was done before that commit.
This fixes booting on a Gigabyte GA-Z97X-SLI mainboard that contains the
following bytes as LoadOptions: 0x41 0x4d 0x42 0x4f ('AMBO').
Reported-by: Thomas Frauendorfer | Miray Software <tf@miray.de>
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
|
|
Commit 018b74d2d69 ("shim: attempt to improve the argument handling") added
added workarounds for a couple of LoadOption problems on some systems, but
introduced a regression since the is_our_path() function can be called with
a NULL start UCS-2 string.
If there's only one string, set start to the start of LoadOptions.
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
|
|
scan-build kindly pointed out:
| shim.c:1568:10: warning: Array access (from variable 'start') results in a null pointer dereference [core.NullDereference]
| while (start[loader_len++] != L'\0');
| ^~~~~~~~~~~~~~~~~~~
| 1 warning generated.
It thinks that because of a bad assumption it's making because of the
test immediately before it, which isn't currently necessary /at all/.
In fact, neither is this loop; it appears to be vestigial and the goal
was done in the loop above it.
This patch just solves for how much space is left arithmetically
instead.
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
This fixes ENABLE_SHIM_DEVEL to actually work, and also makes our "goto
die" failure behavior change (to wait considerably longer) based on it.
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
There's no reason to do the work to set an initial SBAT variable twice,
or to do it /after/ the self check.
This changes it to do it once, before the self check, and then only
raise an error if we're in secure mode.
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
|
|
"So, load options are a giant pain in the ass." - Peter Jones
This patch attempts to workaround two LoadOption problems seen on
my test system: arguments separated with only whitespace (L" ") and
strings that aren't properly NULL terminated.
In addition to my test system, it appears at least one other person
has run into a similar problem and I can reproduce the whitespace
delimiter issue with QEMU+OVMF (OEMU v5.2.0, OVMF v202011).
* https://github.com/rhboot/shim/issues/181
For reference, using QEMU+OVMF and a simple test application,
"test.efi", which does a hexdump of LoadOptions I see the following
when run via the UEFI shell:
FS0:\> test.efi one two three
LoadOptions:
0000: 74 00 65 00 73 00 74 00 2E 00 65 00 66 00 69 00 t.e.s.t...e.f.i.
0016: 20 00 6F 00 6E 00 65 00 20 00 74 00 77 00 6F 00 ..o.n.e...t.w.o.
0032: 20 00 74 00 68 00 72 00 65 00 65 00 00 00 ..t.h.r.e.e...
Signed-off-by: Paul Moore <pmoore2@cisco.com>
|
|
Signed-off-by: Alex Burmashev <alexander.burmashev@oracle.com>
|
|
This re-structures our includes so we can be sure everything is always
including all the system headers in a uniform, predictable way.
Temporarily it also adds a bunch of junk at all the places we use
variadic functions to specifically pick either the MS (cdecl) or ELF
ABIs.
I'm not 100% sure that's all correct (see later patch) but it's enough
to allow this to build.
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
When grub2 invoked Exit() in AArch64 AAVMF, the VM crashed with the
following messsages:
Unloading driver at 0x000B7D7B000
Synchronous Exception at 0x00000000BF5D5E68
AllocatePool: failed to allocate 800 bytes
Synchronous Exception at 0x00000000BF5D5E68
The similar error also showed when I modified MokManager to call
gBS->Exit() at the end of efi_main(). However, if MokManager just
returned, the error never showed. One significant difference is
whether the loaded image was restored or not, and the firmware seems
to need the original ImageBase pointer to do clean-up.
To avoid the potential crash, this commit adds restore_loaded_image() so
that we can restore the loaded image both in start_image() and
do_exit().
Signed-off-by: Gary Lin <glin@suse.com>
|
|
This is needed for shim to verify itself when booting, to make sure that
shim binaries can't be executed anymore after been revoked by SBAT.
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
|
|
A following patch will make shim to verify its .sbat section and it
should be done before doing the OpenSSL initialization. But having
the debugger attached may be useful at this point.
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
|
|
On a typical boot we validate at least two binaries; parsing the SBAT
EFI variable each time, when it should not be changing, is not worth the
effort.
This patch moves the parsing out to some setup code, instead of doing it
during the verification stage.
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
Numbering the error messages in efi_main directly was a mistake, and the
following patches just make it more apparent.
This makes it an enum so we don't have to re-number at more than one
place when we add or remove them.
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
Currently, for an EV_EFI_VARIABLE_AUTHORITY event, the shim puts only
EFI_SIGNATURE_DATA.SignatureData in the VariableData field, but omits
EFI_SIGNATURE_DATA.SignatureOwner. According to reference implementation
in EDK2, the entire EFI_SIGNATURE_DATA is put into the VariableData
field, shown here:
https://github.com/tianocore/edk2/blob/master/SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.c#L1032
|
|
v2 - updated for conflicts and to include documentation (pjones)
|
|
Currently, if you have two boot entries, say one for
\EFI\fedora\shimx64.efi and one for \EFI\devel\shimx64.efi, and you set
the efi variable SHIM_DEBUG=1, both of these will trigger, and you need
to write your debugging scripts to allow each of the builds to continue.
This is a pain.
This patch makes it so on your development build, it will instead check
SHIM_DEVEL_DEBUG, thus meaning you can have it pause for a debugger only
on the development branch and not the OS you need to boot to scp in a
new development build.
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
This is a backport from devel of:
commit 634fd72ac6a6c6c9010c32506d524586826a8637
Author: Peter Jones <pjones@redhat.com>
Date: Fri Nov 22 15:14:22 2019 -0500
Make httpboot.c always get built.
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
The license statements in our source files were getting to be a giant
mess, and mostly they all just say the same thing. I've switched most
of it to SPDX labels, but left copyright statements in place (where they
were not obviously incorrect copy-paste jobs that I did...).
If there's some change here you don't think is valid, let me know and
we can fix it up together.
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
|
|
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
In the version of clang-format I've got locally[0],
WhitespaceSensitiveMacros seems to only work sometimes. That means that
if we ever run it on some particular things, it could seriously mess up
a bunch of our debugging output. That's not great.
In this patch, I've gone ahead and run clang-format on all the macros
that use __LINE__, which are the obvious places this is dangerous, and
then audited the result and fixed anything that's broken (including a
couple of places where it was already broken.)
[0] random:~/devel/github.com/shim/clang-format$ clang-format --version
clang-format version 11.0.0 (Fedora 11.0.0-2.fc33)
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
The DEFAULT_LOADER is a UCS-2 string and the StrLen() function returns the
number of UCS-2 encoded characters in the string. But the allocated memory
is in bytes, so only half of the needed memory to store it is allocated.
This leads to a buffer overrun when the StrCpy() function attempts to copy
the DEFAULT_LOADER to the allocated buffer.
Fixes: 354bd9b1931 ("Actually check for errors from set_second_stage()")
Reported-by: Stuart Hayes <stuart_hayes@dell.com>
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
|
|
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
Signed-off-by: Peter Jones <pjones@redhat.com>
Upstream: pr#213
|
|
This adds support for multiple signatures. It first tries validating
the binary by hash, first against our dbx lists, then against our db
lists. If it isn't allowed or rejected at that step, it continues to
the normal routine of checking all the signatures.
At this point it does *not* reject a binary just because a signature is
by a cert on a dbx list, though that will override any db list that
certificate is listed on. If at any point any assertion about the
binary or signature list being well-formed fails, the binary is
immediately rejected, though we do allow skipping over signatures
which have an unsupported sig->Hdr.wCertificateType.
Signed-off-by: Peter Jones <pjones@redhat.com>
Upstream: pr#210
|
|
Potential new signing strategies ( for example signing grub, fwupdate
and vmlinuz with separate certificates ) require shim to support a
vendor provided bundle of trusted certificates and hashes, which allows
shim to trust EFI binaries matching either certificate by signature or
hash in the vendor_db. Functionality is similar to vendor_dbx.
This also improves the mirroring quite a bit.
Upstream: pr#206
|
|
Signed-off-by: Peter Jones <pjones@redhat.com>
Upstream: pr#206
|
|
Signed-off-by: Peter Jones <pjones@redhat.com>
Upstream: pr#212
|
|
The "TCG PC Client Specific Platform Firmware Profile Specification" says
that when measuring a PE/COFF image, the TCG_PCR_EVENT2 structure Event
field MUST contain a UEFI_IMAGE_LOAD_EVENT structure.
Currently an empty UEFI_IMAGE_LOAD_EVENT structure is passed so users only
have the hash of the PE/COFF image, but not information such the file path
of the binary.
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Upstream-commit-id: c252b9ee94c
|
|
When shim loads the second stage loader (e.g: GRUB) the FilePath field of
the EFI_LOADED_IMAGE structure isn't updated with the path of the loaded
binary. So it still contains the file path of the shim binary.
This isn't a problem since the file path is currently not used. But should
be used to set the DevicePath field of the EFI_IMAGE_LOAD_EVENT structure
that is logged when measuring the PE/COFF binaries. In that case the TPM
Event Log will have an incorrect file path for the measured binary, i.e:
$ hexdump -Cv /sys/kernel/security/tpm0/binary_bios_measurements
...
00000a50 00 00 00 00 00 00 04 04 34 00 5c 00 45 00 46 00 |........4.\.E.F.|
00000a60 49 00 5c 00 72 00 65 00 64 00 68 00 61 00 74 00 |I.\.r.e.d.h.a.t.|
00000a70 5c 00 73 00 68 00 69 00 6d 00 78 00 36 00 34 00 |\.s.h.i.m.x.6.4.|
00000a80 2e 00 65 00 66 00 69 00 00 00 7f ff 04 00 00 00 |..e.f.i.........|
00000a90 00 00 00 00 00 00 af 08 00 00 00 0d 00 00 00 b5 |................|
00000aa0 cd d0 8f bb 16 31 e2 80 8b e8 58 75 c9 89 18 95 |.....1....Xu....|
00000ab0 d2 de 15 15 00 00 00 67 72 75 62 5f 63 6d 64 20 |.......grub_cmd |
00000ac0 73 65 74 20 70 61 67 65 72 3d 31 00 08 00 00 00 |set pager=1.....|
...
So update the EFI_LOADED_IMAGE structure with the second stage loader file
path to have the correct value in the log, i.e:
$ hexdump -Cv /sys/kernel/security/tpm0/binary_bios_measurements
...
00000a50 00 00 00 00 00 00 04 04 34 00 5c 00 45 00 46 00 |........4.\.E.F.|
00000a60 49 00 5c 00 72 00 65 00 64 00 68 00 61 00 74 00 |I.\.r.e.d.h.a.t.|
00000a70 5c 00 67 00 72 00 75 00 62 00 78 00 36 00 34 00 |\.g.r.u.b.x.6.4.|
00000a80 2e 00 65 00 66 00 69 00 00 00 7f ff 04 00 00 00 |..e.f.i.........|
00000a90 00 00 00 00 00 00 af 08 00 00 00 0d 00 00 00 b5 |................|
00000aa0 cd d0 8f bb 16 31 e2 80 8b e8 58 75 c9 89 18 95 |.....1....Xu....|
00000ab0 d2 de 15 15 00 00 00 67 72 75 62 5f 63 6d 64 20 |.......grub_cmd |
00000ac0 73 65 74 20 70 61 67 65 72 3d 31 00 08 00 00 00 |set pager=1.....|
...
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Upstream-commit-id: cd7d42d493d
|
|
This changes shim_init() to check for errors from set_second_stage().
In order to make that work, it also does the following:
- correctly /always/ allocate second_stage, not sometimes allocate and
sometimes point at .data
- test for LoadOptionSize == 0 and return success
- print an error message for the failure so we can see it.
Signed-off-by: Peter Jones <pjones@redhat.com>
Upstream-commit-id: 354bd9b1931
|
|
Signed-off-by: Peter Jones <pjones@redhat.com>
Upstream-commit-id: 173d35fe8f5
|
|
Some versions of OpenSSL seem to go back and forth as to whether NULL
for these names are okay. Don't risk it.
Signed-off-by: Peter Jones <pjones@redhat.com>
Upstream-commit-id: 46b76a01717
|
|
Signed-off-by: Peter Jones <pjones@redhat.com>
Upstream-commit-id: 1870bae7960
|
|
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
|
|
Signed-off-by: Peter Jones <pjones@redhat.com>
Upstream-commit-id: fc6b0bca84e
|
|
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: 750584c20775 ("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
|
|
Signed-off-by: Peter Jones <pjones@redhat.com>
Upstream-commit-id: dad59f8c0f36
|
|
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
Signed-off-by: Peter Jones <pjones@redhat.com>
|
