According to TCG EFI Protocol Specification for TPM 2.0 family,
all events generated after the invocation of EFI_TCG2_GET_EVENT_LOG
shall be stored in an instance of an EFI_CONFIGURATION_TABLE aka
EFI TCG 2.0 final events table. Hence, it is necessary to trigger the
internal switch through calling get_event_log() in order to allow
to retrieve the logs from OS runtime.
Signed-off-by: Lans Zhang <jia.zhang@windriver.com>
For starters; don't allow the "module signing" OID; which ought to
only ever be used for signing kernel modules, not signing EFI binaries.
Signed-off-by: Mathieu Trudel-Lapierre <mathieu.trudel-lapierre@canonical.com>
Try to append the MOK/MOKX list first and then fallback to the normal
SetVariable if the firmware doesn't support EFI_VARIABLE_APPEND_WRITE.
Signed-off-by: Gary Lin <glin@suse.com>
We got the bug report about the usage of APPEND_WRITE that may cause the
failure when writing a variable in Lenovo machines. Although
EFI_VARIABLE_APPEND_WRITE already exists in the UEFI spec for years,
unfortunately, some vendors just ignore it and never implement the
attribute. This commit removes the usage of EFI_VARIABLE_APPEND_WRITE to
make MokManager work on those machines.
https://github.com/rhinstaller/shim/issues/55
Signed-off-by: Gary Lin <glin@suse.com>
Authenticode Certificate length is available in Certificate Table
(inside PE header) and also in signature header(WIN_CERTIFICATE) itself.
Code in 'check_backlist()' method uses length from signature header,
whereas, AuthenticodeVerify() call inside 'verify_buffer()' method uses
the length in signature header. This causes a security vulnerability issue :
Good Scenario : Assume shim1.crt is used for signing grub.efi and
shim1.crt is embedded inside shim.efi. Also, assume shim1.crt got
compromised and therefore it was added in 'dbx' database. Now, when
shim.efi will attempt to load grub.efi, it will fail loading with
log message "Binary is blacklisted" because 'check_blacklist' call
will detect the presence of 'shim1.crt' in 'dbx'.
Vulnerable Scenario : Similar as above. Add 'shim1.crt' in dbx database.
Also, tamper the earlier signed grub.efi file by placing 0x0000 in the
WIN_CERTIFICATE.dwLength.
(Open grub.efi/vmlinuz signed binary with hex editor.
Go to 0x128 address and read out the address from 0x128 until
0x12B in little Indian order from right to left.
Jump to the address from 0x128 address area.
First 8bytes are the signature header area which consist of
signature size(4bytes), revision(2bytes) and type(2bytes).
So tamper the first 4 bytes for signature size and save the binary.
)
With this tampered grub.efi, shim.efi loads it successfully because
'check_blacklist()' call fails to detect the presence of shim1.crt in 'dbx'
database.
Signed-off-by: Sachin Agrawal <sachin.agrawal@intel.com>
Also update Cryptlib to edk2 r19218
- Undefine NO_BUILTIN_VA_FUNCS in Cryptlib/OpenSSL/ for x86_64 to use
the gcc builtins and remove all EFIAPI from the functions
- Move the most of defines into the headers instead of Makefile
- Remove the global variable 'timeval'
- Remove the unused code: crypto/pqueue/* and crypto/ts/*
- Include bn.h in MokManager.c due to the changes in openssl
Signed-off-by: Gary Lin <glin@suse.com>
When fallback.efi is not present, the should_use_fallback error path
attempts to close a file that has already been closed, resulting in a
hang. This issue only affects certain systems.
This is a regression from version 0.8 and was introduced by commit
4794822.
Signed-off-by: Benjamin Antin <ben.antin@endlessm.com>
Fix the compilation error from gcc:
shim.c: In function ‘handle_image’:
shim.c:1121:15: error: unused variable ‘size’ [-Werror=unused-variable]
unsigned int size;
^~~~
Signed-off-by: Gary Lin <glin@suse.com>
This commit adds the basic support for HTTPBoot, i.e. to fetch
the next stage loader with the HTTP protocol.
It requires gnu-efi >= 3.0.3 to support the URI device path and
Ip4Config2 or Ip6Config protocol support in the UEFI implementation.
To build shim.efi with HTTPBoot support:
make ENABLE_HTTPBOOT=1 shim.efi
Signed-off-by: Gary Ching-Pang Lin <glin@suse.com>
On baytrail, we've got 32-bit firmware, 32-bit efi utilities, and 64-bit
kernel. So since most distros will want 32+64 EFI media booting a
64-bit kernel, we have to name them better on the filesystem.
Signed-off-by: Peter Jones <pjones@redhat.com>
Nick Clifton wrote to me and explained:
Subject: SHIM - objcopy version check broken by RHEL 7.3 binutils
Hi Peter,
We (the tools group) have run across a small problem with the shim
package for RHEL 7.3, whilst testing out a new version of the
binutils. It complains that it needs a version of objcopy that is
>= 2.23, despite the fact that the version is actually 2.25.1.
I tracked the problem down to an extraneous space at the end of the
version string being produced by objcopy:
"GNU objcopy version 2.25.1-8.el7 "
The Makefile in the shim package uses this rule to test the version of
objcopy:
OBJCOPY_GTE224 = $(shell expr `$(OBJCOPY) --version |grep ^"GNU objcopy" | sed 's/^.* //g' | cut -f1-2 -d.` \>= 2.24)
But, because of that extra space, the sed expression clips the entire
line and so the test fails.
The extra space is there because normally the version number would be
followed by a date. For example:
"GNU objcopy version 2.23.52.0.1-56.el7 20130226"
So in this case the sed will extract the date, not the version number,
but the test will still pass.
I could fix the binutils to remove the space, although it would be a
bit messy and it would not fix the problem when a date is appended to
the version number. Instead, I would like to propose a small patch to
the shim Makefile. If you change the line to:
OBJCOPY_GTE224 = $(shell expr `$(OBJCOPY) --version |grep ^"GNU objcopy" | sed 's/^.version //g' | cut -f1-2 -d.` \>= 2.24)
then the test will work as intended, with or without an extra space at
the end of the version and with or without a date appended.
Would it be possible to have this change added to the shim package ?
Cheers
Signed-off-by: Peter Jones <pjones@redhat.com>
Add support for measuring the MOK database and secure boot state into a
TPM, and do the same for the second stage loader. This avoids a hole in
TPM measurement between the firmware and the second stage loader.
The second stage set is not working after commit
3322257e61 for those which load option
only have one string.
Signed-off-by: Ivan Hu <ivan.hu@canonical.com>
I found a machine whose BDS gives us relative paths, yay! The rest of
the code still works without that leading slash, so just make it one
more item we let through our StrnCaseCmp() filter.
Signed-off-by: Peter Jones <pjones@redhat.com>
ExitBootServices() and Exit() should both clean these up anyway, but we
should do the right thing nonetheless.
Signed-off-by: Peter Jones <pjones@redhat.com>
We decide if it's a full path by if it starts with \\EFI\\. That's
quite lazy, but we can't just check \\ like you'd hope, because we need
to stay compatible with what we've set as DEFAULT_LOADER in the past,
and I don't feel like writing the full path traversal file test.
Signed-off-by: Peter Jones <pjones@redhat.com>
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>
This is mostly for debugging, so it's not a real problem if it's not
used right now. I just like having it handy.
Signed-off-by: Peter Jones <pjones@redhat.com>
My favorite part of -Wsign-compare is how it shows different results on
different arches for no obvious reason.
Signed-off-by: Peter Jones <pjones@redhat.com>
It turned out that my previous crash fix(*) was wrong.
We actually always used the gcc built-in va functions instead of
the "real" va functions for EFIAPI, and we are just lucky that
ERR_add_error_data didn't crash before.
This commit copies the va functions from MdePkg/Include/Base.h
in edk2 and introdues NO_BUILTIN_VA_FUNCS for x86_64, so that all
the x86_64 build will adopt the new va functions. For safety,
I also added EFIAPI to all the functions which use va_* to avoid
the potential trouble.
(*) a7f4b26cc3
Signed-off-by: Gary Ching-Pang Lin <glin@suse.com>
Building 0.9 with GNU Make 4.0 fails with the following error:
Makefile:4: *** Recursive variable 'RELEASE' references itself (eventually). Stop.
Change RELEASE to simply-expanded.
Signed-off-by: Linn Crosetto <linn@hpe.com>
According to the gcc5 porting guideline (*), gcc5 defaults to
-std=gnu11 instead of -std=gnu89. Append -std=gnu89 to CFLAGS
to avoid the potential problems.
(*) https://gcc.gnu.org/gcc-5/porting_to.html
Based on the patch from Cristian Rodriguez <crrodriguez@opensuse.org>
Signed-off-by: Gary Ching-Pang Lin <glin@suse.com>
Without declaring EFIAPI for ERR_add_error_vdata, shim would crash
while verifying the loaded image.
Signed-off-by: Gary Ching-Pang Lin <glin@suse.com>
