| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
If the specified second stage loader does not exist (invalid
parameter), fall back to the DEFAULT_LOADER. This avoids failing
the boot on any garbage that made it through the load option parser
as a second stage loader name.
Bug-Ubuntu: https://bugs.launchpad.net/bugs/1937115
|
|
On Dell hardware booted in UEFI with option TPM 1.2 "On without Pre-Boot
Measurements", it appears that `tpm_log_event()` fails with Unsupported,
which causes Shim to abort due to believing it couldn't set up the
MokListRT, MokListXRT and SbatLevelRT variables.
This patch ignore the error when trying to write to the TPM and sets the
TPM as 'defective' to not try to write to it anymore.
Signed-off-by: Renaud Métrich <rmetrich@redhat.com>
|
|
Copying the value of datasize_in to two further variables and then using
all three randomly in the code makes it hard to read.
datasize_in is never changed in generate_hash() so we can do with this
parameter alone. Rename it to datasize.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
|
|
On Arch Linux, the GCC version of "limits.h" is in the "include-fixed" instead
of the "include" directory. It needs to be included in the include directories
list, otherwise attempting to compile the test suite fails with the following
error:
In file included from /usr/include/efivar/efivar-dp.h:22,
from /usr/include/efivar/efivar.h:238,
from include/test.h:51,
from shim.h:68,
from csv.c:6:
/usr/include/limits.h:124:16: fatal error: limits.h: No such file or directory
124 | # include_next <limits.h>
| ^~~~~~~~~~
compilation terminated.
|
|
The SBAT variable is defined as ASCII, but the SBAT section in a binary was defined as UTF-8. These should match.
Use ASCII rather than UTF-8, because naive parsing of UTF-8 could lead to unexpected results. For example the character 'ä' can be encoded as 0xe4 or as 0x61 0x0308, and these should be considered equivalent. The shim is not smart enough to do this. This could lead to missed verifications, if the variable and section use different encodings.
Define everything as ASCII. It's sad not to be able to have 🦀 in our bootloader names, and potentially annoying for vendor names as well, but oh well.
|
|
Data after a NUL byte should be ignored.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
|
|
.sbat sections contain user supplied data. We should not assume that it is
well formed. The last line feed might be missing or it might not be at the
end of the file. Instead one or more \0 might follow.
In parse_csv_data() variable 'line' is a pointer with a value between
the values of 'data' and 'data_end'.
There is no reason to check that it is non-zero after assigning it
from 'data' as we already check 'data'.
Instead at the beginning of the file and after each line we must check that
we have not reached the end of the file marked by a '\0' character.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
|
|
Signed-off-by: Esther Shimanovich eshimanovich@google.com
|
|
Currently valgrind shows a minor issue which is not introduced in this
patch series:
==2595397==
==2595397== HEAP SUMMARY:
==2595397== in use at exit: 16,368 bytes in 48 blocks
==2595397== total heap usage: 6,953 allocs, 6,905 frees, 9,146,749 bytes allocated
==2595397==
==2595397== 16,368 bytes in 48 blocks are definitely lost in loss record 1 of 1
==2595397== at 0x4845464: calloc (vg_replace_malloc.c:1117)
==2595397== by 0x4087F2: mock_efi_allocate_pool (test.c:72)
==2595397== by 0x4098DE: UnknownInlinedFun (misc.c:33)
==2595397== by 0x4098DE: AllocateZeroPool (misc.c:48)
==2595397== by 0x403D40: get_variable_attr (variables.c:301)
==2595397== by 0x4071C4: import_one_mok_state (mok.c:831)
==2595397== by 0x4072F4: import_mok_state (mok.c:908)
==2595397== by 0x407FA6: test_mok_mirror_0 (test-mok-mirror.c:205)
==2595397== by 0x4035B2: main (test-mok-mirror.c:378)
==2595397==
==2595397== LEAK SUMMARY:
==2595397== definitely lost: 16,368 bytes in 48 blocks
==2595397== indirectly lost: 0 bytes in 0 blocks
==2595397== possibly lost: 0 bytes in 0 blocks
==2595397== still reachable: 0 bytes in 0 blocks
==2595397== suppressed: 0 bytes in 0 blocks
==2595397==
This is because we're doing get_variable_attr() on the same variable
more than once and saving the value to our variables table. Each
additional time we do so leaks the previous one.
This patch solves the issue by not getting the variable again if it's
already set in the table, and adds a test case to check if we're doing
get_variable() of any variety on the same variable more than once.
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
Test that our mok mirroring doesn't ever try to delete any variable that
it has previously created, and that it properly mirrors at least
MokList, MokListX, and SbatLevel, at least when variables actually work.
These tests will fail (rather a lot) without 7f64fd6da9458b73c4.
Currently valgrind shows a memory leak in this code which is not
introduced in this patch series. Since all of our memory is freed on
Exit() or when kernel does ExitBootServices(), this doesn't have any
significant repercussions.
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
This adds a simple implementation of ST->ConfigurationTable,
ST->NumberOfTableEntries, and BS->InstallConfigurationTable to our test
harness.
Currently it is limited at 1024 entries, but that should be well more
than enough for any tests we've currently considered.
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
For testing of the mok mirroring behavior, we have to be able to account
for what variable calls happened and in what order.
In order to support that, this patch adds 8 callbacks:
mock_set_variable_pre_hook()
mock_set_variable_post_hook()
mock_get_variable_pre_hook()
mock_get_variable_post_hook()
mock_get_next_variable_name_pre_hook()
mock_get_next_variable_name_post_hook()
mock_query_variable_info_pre_hook()
mock_query_variable_info_post_hook()
The pre hooks each take the same arguments as their mocked namesake, and
they fire before any input validation. The post hooks take an
additional EFI_STATUS argument. The post hook fires immediately before
any return from the mocked namesake function. For SetVariable(), the
arguments when the post hook fires are the current contents of the
variable if status is EFI_SUCCESS, and whatever arguments were passed in
if status is any other value. For everything else, the arguments are
the correct results on EFI_SUCCESS, and whatever was passed in if status
is any other value.
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
Some tests will need variables, and so we need a mock implementation of
the various calls relating to them.
This patch adds implementations for the EFI Runtime Services calls
GetVariable(), SetVariable(), GetNextVariableName(), and
QueryVariableInfo(). Additionally, it enforces tunable limits on
storage for variables, and (with only a little work) the limits can be
different for SetVariable() vs what is returned by QueryVariableInfo().
That is, it can lie to you like real systems do.
Signed-off-by: Peter Jones <pjones@redhat.com>
|
