| Age | Commit message (Collapse) | Author |
|---|
|
scan-build invoked clang in a way that complains about our
SIGNATURE_XX() macro's sizes being used to assign to things that are
that size in post-process-pe.c.
This patch makes them cast the results to the appropriately sized type.
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
When using clang-analyzer, scan-build sets CC to
/usr/bin/../libexec/ccc-analyzer, which for whatever reason when we're
in the sub-make to build gnu-efi, then gets confused and invokes gcc
rather than clang. This causes gnu-efi's attempt to check which
compiler it's using to fail, because "/usr/bin/../libexec/ccc-analyzer
-v" invokes GCC. At that point ccc-analyzer complains that it can't
find the clang invocation in its own output, which it chose not to use
clang for, as such:
/usr/bin/../libexec/ccc-analyzer -I/home/pjones/devel/github.com/shim/worktree/gnu-efi//lib -I/home/pjones/devel/github.com/shim/worktree/gnu-efi/inc -I/home/pjones/devel/github.com/shim/worktree/gnu-efi/inc/x86_64 -I/home/pjones/devel/github.com/shim/worktree/gnu-efi/inc/protocol -Wno-error=pragmas -mno-red-zone -mno-avx -fpic -Os -Wall -Wextra -Wno-missing-field-initializers -Werror -fshort-wchar -fno-strict-aliasing -ffreestanding -fno-stack-protector -fno-stack-check -nostdinc -isystem /home/pjones/devel/github.com/shim/worktree/gnu-efi/../include/system -isystem /usr/lib/gcc/x86_64-redhat-linux/11/include -DCONFIG_x86_64 -DGNU_EFI_USE_MS_ABI -DGNU_EFI_USE_EXTERNAL_STDARG -maccumulate-outgoing-args --std=c11 -c /home/pjones/devel/github.com/shim/worktree/gnu-efi//lib/smbios.c -o smbios.o
could not find clang line
make[3]: *** [/home/pjones/devel/github.com/shim/worktree/gnu-efi//lib/../Make.rules:52: smbios.o] Error 1
This patch passes CCC_CC=$(COMPILER) to the gnu-efi sub-make, which
forces ccc-analyzer to use $(COMPILER), which is still clang.
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
Support for updating SBAT revocations to latest or previous revocations.
Allow SBAT revocations to be reset to empty metadata only when UEFI
Secure Boot is disabled.
Signed-off-by: Jan Setje-Eilers <Jan.SetjeEilers@oracle.com>
|
|
Currently, system firmware has no means to discover that an EFI
Application is compatible with the security feature variously known as
NX or w^x.
Since at least Revision 8.1, the PE spec supports setting a flag the
Optional Header's DllCharacteristics field to inform loaders that an
application supports being loaded with NX enabled.
In the case of UEFI, there are several things that should be enabled if
this flag is set:
- EFI_BOOT_SERVICES.AllocatePages() with MemoryType = EfiLoaderCode,
EfiBootServicesCode, EfiRuntimeServicesCode, etc, currently must set
memory as rwx. This flag set implies that rw- is appropriate, and
that the application knows how to use the EFI_MEMORY_ATTRIBUTE
protocol to change that to r-x.
- EFI_BOOT_SERVICES.AllocatePool() - same as AllocatePages()
- EFI_BOOT_SERVICES.LoadImage()
- currently must set the stack as rwx. This flag states that it is
allowed to be rw-
- currently a binary can probably have writable PLTs? This flag
allows the loader to not set them writable
- I have heard that some firmwares have the 0 page mapped rwx.
Obviously this should not be done.
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
This adds a new MoK variable, MokPolicy (&MokPolicyRT) that's intended
as a bitmask of machine owner policy choices, and the bit
MOK_POLICY_REQUIRE_NX. This bit specifies whether it is permissible to
load binaries which do not support NX mitigations, and it currently
defaults to allowing such binaries to be loaded.
The broader intention here is to migrate all of the MoK policy variables
that are really just on/off flags to this variable.
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
This adds support in our PE loader for NX support utilizing the
EFI_MEMORY_ATTRIBUTE protocol. Specifically, it changes the loader such
that:
- binaries without the EFI_IMAGE_DLLCHARACTERISTICS_NX_COMPAT flag set
in the Optional Header are rejected as EFI_UNSUPPORTED
- binaries with non-discardable sections that have both the
EFI_SCN_MEM_WRITE and EFI_SCN_MEM_EXECUTE flags set are rejected as
EFI_UNSUPPORTED
- if the EFI_MEMORY_ATTRIBUTE protocol is installed, then:
- sections without the EFI_SCN_MEM_READ flag set will be marked with
EFI_MEMORY_RP
- sections without the EFI_SCN_MEM_WRITE flag set will be marked with
EFI_MEMORY_RO
- sections without the EFI_SCN_MEM_EXECUTE flag set will be marked
with EFI_MEMORY_XP
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
This patch adds some missing definitions for PE header flags. We don't
use all of them, but it's less confusing with the list matching the
spec, except where the spec is obviously wrong.
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
There is no 's' argument to post-process-pe, so we shouldn't tell getopt
that there is.
This patch takes the 's' out of the getopt short option list.
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
Heavily inspired by Matthew Garrett's patch "Allow additional certificates
to be loaded from a signed binary".
Add support for loading a binary, verifying its signature, and then
scanning it for embedded certificates. This is intended to make it
possible to decouple shim builds from vendor signatures. In order to
add new signatures to shim, an EFI Signature List should be generated
and then added to the .db section of a well-formed EFI binary. This
binary should then be signed with a key that shim already trusts (either
a built-in key, one present in the platform firmware or
one present in MOK) and placed in the same directory as shim with a
filename starting "shim_certificate" (eg, "shim_certificate_oracle").
Shim will read multiple files and incorporate the signatures from all of
them. Note that each section *must* be an EFI Signature List, not a raw
certificate.
Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
|
|
Separate out image reading from image launch in order to be able to load
an image without executing it.
Signed-off-by: Matthew Garrett <mgarrett@aurora.tech>
Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
|
|
In the future we will want to examine binaries without wanting to
execute them. Create verify_image based off existing handle_image
code.
Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
|
|
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
This makes SHIM_VERBOSE / SHIM_DEVEL_VERBOSE work the same way as
SHIM_DEBUG / SHIM_DEVEL_DEBUG when shim is built with ENABLE_SHIM_DEVEL
set.
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
Many ASRock boards will not render MokManager correctly if the Unicode
Box Drawing characters are used.
Signed-off-by: Tony Persson <tony@tonypersson.se>
|
|
Now that we've got "objcopy --target efi-app-aarch64" and similar, we
don't have to go through heroic effort to try to make aarch64 builds
work.
This patch updates to a gnu-efi branch that has newer aarch64 crt0 code,
and makes efi_aarch64_efi.lds be nearly identical to efi_x86_64_efi.lds.
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
This is the standard Contributor Covenant.
See-also: https://www.contributor-covenant.org/
Signed-off-by: Robbie Harwood <rharwood@redhat.com>
|
|
Within previous versions of shim the MokListTrusted var did not
exist. The user had to opt in to using the feature.
Change the default behavior to an opt out model. Since old
shims will not have the BS MokListTrusted set, use inverse
logic that sets the MokListTrustedRT to 1 when the boot
service variable is missing.
Many Linux distros carry out of tree patches to trust the mok
keys by default. These out of tree patches can be dropped
when using a Linux kernel that supports MokListTrustedRT.
Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
|
|
* test_strncpy(). The test intentionally copies less than the total length
of the string, so it looks like there is nothing we can do about it in
the test other than explicitly ignoring the warnings.
inlined from ‘test_strncpy’ at test-str.c:943:2:
/usr/include/x86_64-linux-gnu/bits/string_fortified.h:106:10: error: ‘__builtin_strncpy’
output may be truncated copying 1 byte from a string of length 8191 [-Werror=stringop-truncation]
106 | return __builtin___strncpy_chk (__dest, __src, __len, __bos (__dest));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
...
* test_strcat(). The fix for the warning below is to avoid using overlapping
buffers in src and dst. This is actually a requirement for both strcat() and
strncpy(), so fix both functions.
inlined from ‘test_strcat’ at test-str.c:1052:2:
/usr/include/x86_64-linux-gnu/bits/string_fortified.h:128:10: error: ‘__builtin___strcat_chk’
accessing 4097 or more bytes at offsets 4096 and 0 may overlap 1 byte at offset 4096 [-Werror=restrict]
128 | return __builtin___strcat_chk (__dest, __src, __bos (__dest));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
...
Signed-off-by: Alexey Kodanev <aleksei.kodanev@bell-sw.com>
|
|
$ make test
...
mock-variables.c: In function 'mock_sv_attrs_match':
mock-variables.c:448:23: error: conversion from 'long unsigned int' to 'UINT32'
{aka 'unsigned int'} changes value from '18446744073709551551' to '4294967231' [-Werror=overflow]
448 | UINT32 mask = ~EFI_VARIABLE_APPEND_WRITE;
| ^
cc1: all warnings being treated as errors
Signed-off-by: Alexey Kodanev <aleksei.kodanev@bell-sw.com>
|
|
On Debian(-derived) systems low-level system headers are under
/usr/include/<multi-arch path>, so look there too.
Otherwise we see stuff like:
gcc -O2 -fno-diagnostics-color -ggdb -std=gnu11 -isystem <foo>/shim.git/include/system -I<foo>/shim.git/gnu-efi/inc -I<foo>/shim.git/gnu-efi/inc/ia32 -I<foo>/shim.git/gnu-efi/inc/protocol -Iinclude -iquote . -isystem /usr/include -isystem /usr/lib/gcc/i686-linux-gnu/11/include -mno-mmx -mno-sse -mno-red-zone -nostdinc -maccumulate-outgoing-args -m32 -DMDE_CPU_IA32 -DPAGE_SIZE=4096 -fshort-wchar -fno-builtin -rdynamic -fno-inline -fno-eliminate-unused-debug-types -fno-eliminate-unused-debug-symbols -gpubnames -grecord-gcc-switches -Wall -Wextra -Wno-missing-field-initializers -Wsign-compare -Wno-deprecated-declarations -Wno-unused-but-set-variable -Wno-unused-variable -Wno-pointer-sign -Werror -Werror=nonnull -Werror=nonnull-compare -DEFI_FUNCTION_WRAPPER -DGNU_EFI_USE_MS_ABI -DPAGE_SIZE=4096 -DSHIM_UNIT_TEST -DDEFAULT_DEBUG_PRINT_STATE=0 -isystem include-fixed -o test-csv csv.c test-csv.c test.c libefi-test.a -lefivar
In file included from /usr/include/bits/errno.h:26,
from /usr/include/errno.h:28,
from /usr/include/efivar/efivar.h:24,
from include/test.h:51,
from shim.h:68,
from csv.c:6:
/usr/include/linux/errno.h:1:10: fatal error: asm/errno.h: No such file or directory
1 | #include <asm/errno.h>
| ^~~~~~~~~~~~~
compilation terminated.
In file included from /usr/include/bits/errno.h:26,
from /usr/include/errno.h:28,
from /usr/include/efivar/efivar.h:24,
from include/test.h:51,
from shim.h:68,
from test-csv.c:9:
/usr/include/linux/errno.h:1:10: fatal error: asm/errno.h: No such file or directory
1 | #include <asm/errno.h>
| ^~~~~~~~~~~~~
compilation terminated.
In file included from /usr/include/bits/errno.h:26,
from /usr/include/errno.h:28,
from /usr/include/efivar/efivar.h:24,
from include/test.h:51,
from shim.h:68,
from test.c:7:
/usr/include/linux/errno.h:1:10: fatal error: asm/errno.h: No such file or directory
1 | #include <asm/errno.h>
| ^~~~~~~~~~~~~
compilation terminated.
Signed-off-by: Steve McIntyre <steve@einval.com>
|
|
With -Werror these were causing build failures with stricter gcc:
.../post-process-pe.c: In function 'load_pe':
.../post-process-pe.c:177:55: error: format '%ld' expects argument of type 'long int', but argument 4 has type 'size_t' {aka 'unsigned int'} [-Werror=format=]
.../post-process-pe.c:192:56: error: format '%lu' expects argument of type 'long unsigned int', but argument 4 has type 'UINT64' {aka 'long long unsigned int'} [-Werror=format=]
.../post-process-pe.c:236:31: error: format '%zu' expects argument of type 'size_t', but argument 2 has type 'UINT64' {aka 'long long unsigned int'} [-Werror=format=]
.../post-process-pe.c:39:32: note: in definition of macro 'debug'
.../post-process-pe.c:236:60: note: format string is defined here
.../post-process-pe.c:240:31: error: format '%zu' expects argument of type 'size_t', but argument 2 has type 'UINT64' {aka 'long long unsigned int'} [-Werror=format=]
.../post-process-pe.c:39:32: note: in definition of macro 'debug'
.../post-process-pe.c:240:60: note: format string is defined here
.../post-process-pe.c:274:30: error: format '%zu' expects argument of type 'size_t', but argument 2 has type 'UINTN' {aka 'long unsigned int'} [-Werror=format=]
.../post-process-pe.c:39:32: note: in definition of macro 'debug'
.../post-process-pe.c:274:34: note: format string is defined here
Signed-off-by: Steve McIntyre <steve@einval.com>
|
|
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
Signed-off-by: Robbie Harwood <rharwood@redhat.com>
|
|
Set fail-fast to false to get a more useful picture of results.
Signed-off-by: Robbie Harwood <rharwood@redhat.com>
|
|
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
This implements SBAT verification via the shim_lock protocol
by moving verification inside the existing verify_buffer()
function that is shared by both shim_verify() and handle_image().
The .sbat section is optional for code verified via the shim_lock
protocol, unlike for code that is verified and executed directly
by shim. For executables that don't have a .sbat section,
verification is skipped when using the protocol.
A vendor can enforce SBAT verification for code verified via the
shim_lock protocol by revoking all pre-SBAT binaries via a dbx
update or by using vendor_dbx and then only signing binaries that
have a .sbat section from that point.
Signed-off-by: Chris Coulson <chris.coulson@canonical.com>
|
|
On some platform, like GCP or OVMF which does NOT provide
EFI_GRAPHICS_OUTPUT_PROTOCOL when no display device (or the display device
be disabled). It causes that the "Error: Locate graphic output protocol
fail: (0xE) Not Found." always be showed on console when we enroll MOK
through MokManager. The message box blocked the process of enrolling
MOK and scared user. The error message is introduced by 55163bc82c517 since
15.2. This patch removed the error message.
Signed-off-by: Lee, Chun-Yi <jlee@suse.com>
|
|
Mark this officially as shim 15.5
Signed-off-by: Robbie Harwood <rharwood@redhat.com>
|
|
perror(L"%d sections contain entry point\n") lacks an argument
corresponding to %d.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
|
|
This resolves issue #442
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
Currently, when you boot linux you get a bright red message in the log
and the console like:
Feb 03 13:18:45 localhost.localdomain kernel: mokvar: EFI MOKvar config table is not in EFI runtime memory
We don't like bright red messages on the console, so this patch changes
the memory allocation for the mokvar config table so that it's in
runtime memory.
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
- one missing free
- one minor deadcode issue
- two unchecked allocations
- one debug hexdump of a variable we just freed
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
cov-analysis-linux64-2020.09 is a lot more successful than the older
versions at building, but it still has some... issues. Among them, it
is of the belief that this:
void
foo(char *fmt, ...)
{
__builtin_va_list ap;
__builtin_ms_va_start(ap, fmt); /* <- here */
...
}
is an uninitialized use of "ap".
This patch adds defined(__COVERITY__) to the list of criteria for using
sysv va lists, which it has no such confusion about.
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
Requesting a keystroke when Secure Boot is not enabled and verbosity is
enabled is really annoying.
Signed-off-by: Renaud Métrich <rmetrich@redhat.com>
|
|
The buffer used to read the data in the CSV is declared as a stack variable
in the try_boot_csv() function, but a pointer to the arguments field of the
first boot option is stored in the global first_new_option_args variable.
Later, when is used set the arguments to boot the first entry, the variable
points to memory that no longer exists. This leads to booting an entry with
garbage as arguments instead of the correct value.
Reported-by: Alexander Larsson <alexl@redhat.com>
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
|
|
Introduce a new MOK variable called MokListTrustedRT. It allows an end-user
to decide if they want to trust MOKList keys within the soon to be booted
Linux kernel. This variable does not change any functionality within shim
itself. When Linux boots, if MokListTrustedRT is set and
EFI_VARIABLE_NON_VOLATILE is not set, keys in MokListRT are loaded into the
.machine keyring instead of the .platform keyring.
Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
|
|
In the bug2 section, the first Debian `.sbat` has a `grub,1`
component. But at this point in the story, `grub,1` has been revoked by
the update in the bug1 section. Updated it to `grub,2` so that it passes
that check.
Signed-off-by: Nicholas Bishop <nicholasbishop@google.com>
|
|
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
We see various reports of boot failures because the generated
boot entries contain garbage/tagging that we do not expect, and
that we then parse as a second stage boot loader.
|
|
Simple refactoring that extracts the path checking on the given
loaded image. This will be useful to check if we were booted via
removable media path in other places.
|
|
The name of the SBAT UEFI variable changed from "SBAT" to "SbatLevel" in
27da4170f0fb30acde91a37e0256dfcfe76ea69e. Update the documentation to
match.
Signed-off-by: Nicholas Bishop <nicholasbishop@google.com>
|
|
Several places in e.g. MokManager and our console library use
ST->ConOut->ClearScreen directly, without checking for the existence of
a console output device.
This patch adds function to our console library to do that correctly,
instead of using the bug-prone ad hoc implementation everywhere.
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
There's been some discussion on how to handle machines without console
devices. The consensus so far has been that they should have dummy
ConOut implementations, but that means the first vendor to build a
machine without asking around is in for some surprises.
This patch makes the places where our console library uses ST->ConIn or
ST->ConOut check that they're present before doing so.
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
Seen on Dell PowerEdge R740 when booting with BOOTX64 constantly.
This patch keeps the behaviour previous to commit #1b30c2b by returning
the index of the "Linux" entry.
Then a check is made to find the entry in the current BootOrder:
- if it isn't there, prepend the entry and copy the rest (this enlarges
the BootOrder array by 1)
- if it's there, prepend the entry and copy all remaining entries
------------------------------------------------------------------------------
Example of outputs on a Dell PowerEdge R740:
- 0000 is BOOTX64 entry
- other entries are Dell's default ones (internal, no "Linux" there)
1. Entry not already existing in BootOrder
----
set_boot_order:486: Original nbootorder: 3
Original BootOrder: 0000 0003 0004
:
add_to_boot_list:578: device path: "HD(1,GPT,99D47E76-590F-48FD-8FD6-0A0CE790D635)/\EFI\redhat\shimx64.efi"
find_boot_option:454: Found boot entry "Boot0005" with label "Red Hat Enterprise Linux" for file "\EFI\redhat\shimx64.efi"
add_to_boot_list:623: New nbootorder: 4
BootOrder: 0005 0000 0003 0004
find_boot_options:937: Found directory named "Dell"
update_boot_order:509: nbootorder: 4
BootOrder: 0005 0000 0003 0004
----
2. Entry not existing at all
----
set_boot_order:486: Original nbootorder: 3
Original BootOrder: 0000 0001 0002
:
add_to_boot_list:578: device path: "HD(1,GPT,99D47E76-590F-48FD-8FD6-0A0CE790D635)/\EFI\redhat\shimx64.efi"
add_boot_option:245: Creating boot entry "Boot0005" with label "Red Hat Enterprise Linux" for file "\EFI\redhat\shimx64.efi"
add_boot_option:282: nbootorder: 4
BootOrder: 0005 0000 0001 0002
find_boot_options:937: Found directory named "Dell"
update_boot_order:509: nbootorder: 4
BootOrder: 0005 0000 0001 0002
----
3. Entry already existing in BootOrder
----
set_boot_order:486: Original nbootorder: 4
Original BootOrder: 0000 0005 0001 0002
:
add_to_boot_list:578: device path: "HD(1,GPT,99D47E76-590F-48FD-8FD6-0A0CE790D635)/\EFI\redhat\shimx64.efi"
find_boot_option:454: Found boot entry "Boot0005" with label "Red Hat Enterprise Linux" for file "\EFI\redhat\shimx64.efi"
add_to_boot_list:623: New nbootorder: 4
BootOrder: 0005 0000 0001 0002
find_boot_options:937: Found directory named "Dell"
update_boot_order:509: nbootorder: 4
BootOrder: 0005 0000 0001 0002
----
|
|
entry in optnum"
This reverts commit 1b30c2b9e5ee7d3e305a28a92805152d5cbfc9cb.
This commit was creating duplicated entries when the "Linux" entry was
not already in the BootOrder list, which may happen upon firmware reset.
|
|
Dump the load options before parsing them so that we can
see which things are failing to parse.
|
