| Age | Commit message (Collapse) | Author |
|---|
|
EFI_BOOT_SERVICES includes CopyMem() and SetMem() functions which are
marked EFIAPI, and in the case of CopyMem() does not mark the source
argument as CONST.
This patch makes all our invocations work with that, so (once gnu-efi's
implementation is fixed to match) we can use the existing implementation
as the implementation in a mock EFI_BOOT_SERVICES.
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
In the cloud, all boots are non-interactive with keyboard and console
access either typically not available or prohibited. Also clouds
always do firstboot via fallback. This currently results in an
unacceptable 5s boot delay whilst fallback offers interactive reset
options that cannot be actioned.
In Ubuntu, we'd like to make fallback noninteractive by default
without any boot delays, due to bootspeed impact on firstboot of the
preinstalled images.
Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/shim/+bug/1922581
Signed-off-by: Dimitri John Ledkov <xnox@ubuntu.com>
|
|
Now that we are iterating over all EFI variables to look for duplicate
boot entries, we should use a dynamic buffer, so if the firmware tells
us the buffer is too small for the next variable name we can re-allocate
it to a big enough size.
Signed-off-by: João Paulo Rechi Vita <jprvita@endlessos.org>
|
|
When listing all variables checking for duplicates, print which error
was returned if not EFI_NOT_FOUND (which simply means reached the end of
the list).
Signed-off-by: João Paulo Rechi Vita <jprvita@endlessos.org>
|
|
There is no need to check the parameters of strntoken() twice.
Fixes: c7bb10cf154a ("Tidy up our string primitives...")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
|
|
An error message complaining about missing file BOOTx64.EFI makes no
sense on other architectures.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
|
|
Heinrich correctly noticed that read_file()'s memory allocation failure
error path tested the wrong variable, and thus would never catch the
error condition. The *next* error, file->Read() failing, has the same
incorrect variable usage in its FreePool() invocation.
This fixes it to free the right variable as well.
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
After calling AllocateZeroPool() we must check the returned pointer.
Fixes: 3ce517fdbb4e ("Add a fallback loader for when shim is invoked as BOOTX64.EFI")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
|
|
Some servers (HAProxy) yield Content-Length in lowercase, and shim would
fail to find it.
Signed-off-by: Robbie Harwood <rharwood@redhat.com>
|
|
optnum
The CopyMem() calls in add_to_boot_list() expect that
find_boot_option() returned an index to the matching entry in the
BootOrder array. The previous code returned the numerical portion of
the boot entry label, which in some cases resulted in -1 *
sizeof(CHAR16) being passed to CopyMem() which would in turn corrupt
the running firmware resulting in an exception and a failure to boot
or reset.
|
|
When EBS protection is disabled the code which hooks into EBS is
complied out, but on unhook it's the code which restores Exit() that
is disabled. This appears to be a mistake, and it can result in
writing NULL to EBS in the boot services table.
Fix this by moving the ifdefs to compile out the code to unhook EBS
instead of the code to unhook Exit(). Also ifdef the definition of
system_exit_boot_services to safeguard against its accidental use.
Fixes: 4b0a61dc9a95 ("shim: compile time option to bypass the ExitBootServices() check")
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
|
|
Some UEFI environment such as u-boot doesn't implement
QueryVariableInfo(), so we couldn't rely on the function to estimate the
available space for RT variables. All we can do is to call SetVariable()
directly and check the return value of SetVariable().
Signed-off-by: Gary Lin <glin@suse.com>
|
|
Fix the case where data_size is 0, so config_template is
not implicitly copied like the size calculation above.
upstream-status: https://github.com/rhboot/shim/issues/249
Signed-off-by: Jonathan Yong <jonathan.yong@intel.com>
|
|
The previous commit(*) merged .rel* and .dyn* into .rodata, and this
made ld to generate the wrong size for .rela* sections that covered
other unrelated sections. When the EFI image was loaded, _relocate()
went through the unexpected data and may cause unexpected crash.
This commit moves .rel* and .dyn* out of .rodata in the ld script but
also moves the related variables, such as _evrodata, _rodata_size,
and _rodata_vsize, to the end of the new .dyn section, so that the
crafted pe-coff section header for .rodata still covers our new
.rela and .dyn sections.
(*) 212ba30544f ("arm/aa64 targets: put .rel* and .dyn* in .rodata")
Fix issue: https://github.com/rhboot/shim/issues/371
Signed-off-by: Gary Lin <glin@suse.com>
|
|
Some firmware feeds the LoadOptions with an odd length when booting from
an USB device(*). We should only skip this kind of LoadOptions, not fail
it, or the user won't be able to boot the system from USB or CD-ROM.
(*) https://bugzilla.suse.com/show_bug.cgi?id=1185232#c62
Signed-off-by: Gary Lin <glin@suse.com>
|
|
This adds tests for all the cases we've documented in the
set_second_stage() comments. Each test checks that all of second_stage,
loader_str, and loader_str_size are set correctly.
Note that this adds a dependency on libefivar to build device paths to
test against.
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
This moves set_second_stage() and some of the helper functions it uses
out of shim.c, so that it's easier to write test cases for.
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
Some tests have some complex flows, and it's useful to be able to see
the call path when there's a failure.
This patch adds a very simple traceback printer, along with changing the
test build arguments to include more debug information.
The result you get from this traceback printer just gives you a function
name and the index into its .txt content, so to use it for more than
"which function calls which", you'll need to use eu-addr2line with the
output.
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
This test helper was conspicuously missing, so this patch just adds it
at the obvious place.
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
In some test cases, it may be useful to call libefi.a functions, such as
the device path parsing functions, which allocate pages via
BS->AllocatePool() or BS->AllocatePages.
This patch ads a simple mock implementation of those functions, as well
as the EFI_SYSTEM_TABLE, EFI_BOOT_SERVICES, and EFI_RUNTIME_SERVICES
variables *ST, *BS, and *RT (respectively), and initializes them before
the test cases run.
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
This allows us to use library functions from libefi.a in our test
programs.
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
test.c duplicates a couple of objects (StrnCmp, StrCmp) that are
in libefi.a, as well as SHIM_LOCK_GUID from lib/guid.o. While it's nice
to have these at some places, we need to disable them if we're actually
linking a test case against either of those.
This patch adds HAVE_foo guards around those objects.
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
In some test cases, it's useful to be able to call some of the very
common stuff in gnu-efi's efilib.h (i.e. CompareGuid()), but including
that header itself is too big for me to tackle right now.
This patch adds a few more decls to test.h.
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
pause() is a posix function, and having it named the same as this makes
it hard to include the asm.h header in some test cases.
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
The load options handling is quite complicated and tries to accomodate
several scenarios, but there are currently multiple issues:
- If the supplied LoadOptions is an EFI_LOAD_OPTION structure,
second_stage gets initialized to the entire contents of the OptionalData
field and load_options is initialized to NULL, which means it isn't
possible to pass additional options to the second stage loader (and it
looks like the intention is for this to be supported).
- If the supplied LoadOptions contains 2 or more strings, the code seems
to assume that shim was executed from the UEFI shell and that the first
argument is the path of the shim executable, so it's ignored. But this
breaks the ability to pass additional options to the second stage loader
from BDS on firmware implementations that initialize LoadOptions to just
the OptionalData field of the EFI_LOAD_OPTION, which is what EDK2 seems
to do.
This is moot anyway because this case (strings == 2) doesn't actually seem
to work, as nothing sets loader_len and therefore second_stage is not set
to the custom loader path.
- If the supplied LoadOptions contains a single string that isn't shim's
path, nothing sets loader_len and therefore second_stage isn't set at the
end of set_second_stage.
- set_second_stage replaces L' ' characters with L'\0' - whilst this is
useful to NULL terminate the path for the second stage, it doesn't seem
quite right to do this for the remaining LoadOptions data. Grub's
chainloader command supplies additional arguments as a NULL-terminated
space-delimited string via LoadOptions. Making it NULL-delimited seems to
be incompatible with the kernel's commandline handling, which wouldn't
work for scenarios where you might want to direct-boot a kernel image
(wrapped in systemd's EFI stub) from shim.
- handle_image passes the original LoadOptions to the second stage if
load_options is NULL, which means that the second stage currently always
gets shim's load options.
I've made an attempt to try to fix things. After the initial
checks in set_second_stage, it now does this:
- Tries to parse LoadOptions as an EFI_LOAD_OPTION in order to extract
the OptionalData if it is.
- If it's not an EFI_LOAD_OPTION, check if the first string is the
current shim path and ignore it if it is (the UEFI shell case).
- Split LoadOptions in to a single NULL terminated string (used to
initialize second_stage) and the unmodified remaining data (used to
initialize load_options and load_options_size).
I've also modified handle_image to always set LoadOptions and
LoadOptionsSize. If shim is executed with no options, or is only
executed with a single option to override the second stage loader
path, the second stage is executed with LoadOptions = NULL and
LoadOptionsSize = 0 now.
I've tested this on EDK2 and I can load a custom loader with extra
options from both BDS and the UEFI shell:
FS0:\> shimx64.efi test.efi
LoadOptionsSize: 0
LoadOptions: (null)
FS0:\> shimx64.efi test.efi
LoadOptionsSize: 0
LoadOptions: (null)
FS0:\> shimx64.efi test.efi foo bar
LoadOptionsSize: 16
LoadOptions: foo bar
|
|
Use the stronger "will" rather than "will should". I'm not sure based on
what's there, but suspect "must" would be appropriate instead?
Signed-off-by: Serge Hallyn <serge@hallyn.com>
|
|
1. Use : instead of , to separate a list.
2. Fix spelling of therefore.
3. Pull unrelated clause out of parenthesized clause.
Signed-off-by: Serge Hallyn <serge@hallyn.com>
|
|
An openSUSE user reported(*) that shim 15.4 failed to boot the system
with the following message:
"Could not create MokListXRT: Out of Resources"
In the beginning, I thought it's caused by the growing size of
vendor-dbx. However, we found the following messages after set
SHIM_VERBOSE:
max_var_sz:8000 remaining_sz:85EC max_storage_sz:9000
SetVariable(“MokListXRT”, ... varsz=0x1404) = Out of Resources
Even though the firmware claimed the remaining storage size is 0x85EC
and the maximum variable size is 0x8000, it still rejected MokListXRT
with size 0x1404. It seems that the return values from QueryVariableInfo()
are not reliable. Since this firmware didn't really support Secure Boot,
the variable mirroring is not so critical, so we can just accept the
failure of import_mok_state() and continue boot.
(*) https://bugzilla.suse.com/show_bug.cgi?id=1185261
Signed-off-by: Gary Lin <glin@suse.com>
|
|
On some versions of binutils[0], including binutils-2.23.52.0.1-55.el7,
do not correctly initialize the data when computing the PE optional
header checksum. Unfortunately, this means that any time you get a
build that reproduces correctly using the version of objcopy from those
versions, it's just a matter of luck.
This patch introduces a new utility program, post-process-pe, which does
some basic validation of the resulting binaries, and if necessary,
performs some minor repairs:
- sets the timestamp to 0
- this was previously done with dd using constant offsets that aren't
really safe.
- re-computes the checksum.
[0] I suspect, but have not yet fully verified, that this is
accidentally fixed by the following upstream binutils commit:
commit cf7a3c01d82abdf110ef85ab770e5997d8ac28ac
Author: Alan Modra <amodra@gmail.com>
Date: Tue Dec 15 22:09:30 2020 +1030
Lose some COFF/PE static vars, and peicode.h constify
This patch tidies some COFF and PE code that unnecessarily used static
variables to communicate between functions.
v2 - MAP_PRIVATE was totally wrong...
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
The EFI 1.10 spec (and presumably earlier revisions as well) didn't have
RT->QueryVariableInfo(), and on Chris Murphy's MacBookPro8,2 , that
memory appears to be initialized randomly.
This patch changes it to not call RT->QueryVariableInfo() if the
EFI_RUNTIME_SERVICES table's major revision is less than two, and
assumes our maximum variable size is 1024 in that case.
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
Linux kernel is picky when reserving the memory for x86 and it only
expects BootServicesData:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/x86/platform/efi/quirks.c?h=v5.11#n254
Otherwise, the following error would show during system boot:
Apr 07 12:31:56.743925 localhost kernel: efi: Failed to lookup EFI memory descriptor for 0x000000003dcf8000
Although BootServicesData would be reclaimed after ExitBootService(),
linux kernel reserves MOK config table when it detects the existence of
the table, so it's fine to allocate the table as BootServicesData.
Signed-off-by: Gary Lin <glin@suse.com>
|
|
Commit c6281c6a195edee61185 needs to have included a ". = ALIGN(4096)"
directive before .reloc, but fails to do so.
As a result, binutils, which does not care about the actual binary
format's constraints in any way, does not enforce the section alignment,
and it will not load.
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
This is purely superficial, as the commit points at the shim-15.4 branch
already, but some people have found it confusing.
This fixes issue #356.
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
In 65be350308783a8ef537246c8ad0545b4e6ad069, import_mok_state() is split
up into a function that manages the whole mok state, and one that
handles the state machine for an individual state variable.
Unfortunately, the code that initializes the global ignore_db and
user_insecure_mode was copied from import_mok_state() into the new
import_one_mok_state() function, and thus re-initializes that state each
time it processes a MoK state variable, before even assessing if that
variable is set. As a result, we never honor either flag, and the
machine owner cannot disable trusting the system firmware's db/dbx
databases or disable validation altogether.
This patch removes the extra re-initialization, allowing those variables
to be set properly.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
|
|
Mark this officially as shim 15.4
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
For every problem, there exists a solution which is simple, elegant, and
wrong. d74629207188d290810db15dbfe91a89e7751ffb is that solution.
This patch leaves that intact, but adds a .rodata section wrapping
.rel/.rela and .dynsym/.dynstr., so that they are correctly
incorporated into the authenticode hash.
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
This adds dprint() to a bunch of our error returns.
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
|
|
This fixes a memory leak caused by test_verify_sbat_null_sbat_section()
not calling cleanup_sbat_var().
Before:
==2591367== Memcheck, a memory error detector
==2591367== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==2591367== Using Valgrind-3.17.0 and LibVEX; rerun with -h for copyright info
==2591367== Command: ./test-sbat
==2591367==
==2591367==
==2591367== HEAP SUMMARY:
==2591367== in use at exit: 56 bytes in 1 blocks
==2591367== total heap usage: 17 allocs, 16 frees, 5,382 bytes allocated
==2591367==
==2591367== 56 bytes in 1 blocks are definitely lost in loss record 1 of 1
==2591367== at 0x4845464: calloc (vg_replace_malloc.c:1117)
==2591367== by 0x402AEB: parse_sbat_var_data (sbat.c:234)
==2591367== by 0x40189D: UnknownInlinedFun (test-sbat.c:445)
==2591367== by 0x40189D: main (test-sbat.c:1033)
==2591367==
==2591367== LEAK SUMMARY:
==2591367== definitely lost: 56 bytes in 1 blocks
==2591367== indirectly lost: 0 bytes in 0 blocks
==2591367== possibly lost: 0 bytes in 0 blocks
==2591367== still reachable: 0 bytes in 0 blocks
==2591367== suppressed: 0 bytes in 0 blocks
==2591367==
==2591367== For lists of detected and suppressed errors, rerun with: -s
==2591367== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
After:
==2645037== Memcheck, a memory error detector
==2645037== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==2645037== Using Valgrind-3.17.0 and LibVEX; rerun with -h for copyright info
==2645037== Command: ./test-sbat
==2645037==
==2645037==
==2645037== HEAP SUMMARY:
==2645037== in use at exit: 0 bytes in 0 blocks
==2645037== total heap usage: 17 allocs, 17 frees, 5,382 bytes allocated
==2645037==
==2645037== All heap blocks were freed -- no leaks are possible
==2645037==
==2645037== For lists of detected and suppressed errors, rerun with: -s
==2645037== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
Valgrind was showing me a memory leak in the tests, and it's because of
several minor problems:
- the allocation isn't actually ever a list entry, because the entry
array was before the linked list in the allocations
- the comparison for "first" when trying to free it is incorrect, so
that was never getting set.
- we never free the test variable data that was parsed
- we're never calling cleanup_sbat_var() from several test cases.
This fixes these issues.
Before:
==2525955==
==2525955== HEAP SUMMARY:
==2525955== in use at exit: 181 bytes in 3 blocks
==2525955== total heap usage: 17 allocs, 14 frees, 2,310 bytes allocated
==2525955==
==2525955== 15 bytes in 1 blocks are definitely lost in loss record 1 of 3
==2525955== at 0x4845464: calloc (vg_replace_malloc.c:1117)
==2525955== by 0x401D21: UnknownInlinedFun (test-sbat.c:937)
==2525955== by 0x401D21: main (test-sbat.c:1043)
==2525955==
==2525955== 56 bytes in 1 blocks are definitely lost in loss record 2 of 3
==2525955== at 0x4845464: calloc (vg_replace_malloc.c:1117)
==2525955== by 0x402ACB: parse_sbat_var_data (sbat.c:234)
==2525955== by 0x40189D: UnknownInlinedFun (test-sbat.c:445)
==2525955== by 0x40189D: main (test-sbat.c:1029)
==2525955==
==2525955== 110 bytes in 1 blocks are definitely lost in loss record 3 of 3
==2525955== at 0x4845464: calloc (vg_replace_malloc.c:1117)
==2525955== by 0x402ACB: parse_sbat_var_data (sbat.c:234)
==2525955== by 0x401D67: UnknownInlinedFun (test-sbat.c:943)
==2525955== by 0x401D67: main (test-sbat.c:1043)
==2525955==
==2525955== LEAK SUMMARY:
==2525955== definitely lost: 181 bytes in 3 blocks
==2525955== indirectly lost: 0 bytes in 0 blocks
==2525955== possibly lost: 0 bytes in 0 blocks
==2525955== still reachable: 0 bytes in 0 blocks
==2525955== suppressed: 0 bytes in 0 blocks
==2525955==
==2525955== For lists of detected and suppressed errors, rerun with: -s
==2525955== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 0 from 0)
After:
==2591367== Memcheck, a memory error detector
==2591367== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==2591367== Using Valgrind-3.17.0 and LibVEX; rerun with -h for copyright info
==2591367== Command: ./test-sbat
==2591367==
==2591367==
==2591367== HEAP SUMMARY:
==2591367== in use at exit: 56 bytes in 1 blocks
==2591367== total heap usage: 17 allocs, 16 frees, 5,382 bytes allocated
==2591367==
==2591367== 56 bytes in 1 blocks are definitely lost in loss record 1 of 1
==2591367== at 0x4845464: calloc (vg_replace_malloc.c:1117)
==2591367== by 0x402AEB: parse_sbat_var_data (sbat.c:234)
==2591367== by 0x40189D: UnknownInlinedFun (test-sbat.c:445)
==2591367== by 0x40189D: main (test-sbat.c:1033)
==2591367==
==2591367== LEAK SUMMARY:
==2591367== definitely lost: 56 bytes in 1 blocks
==2591367== indirectly lost: 0 bytes in 0 blocks
==2591367== possibly lost: 0 bytes in 0 blocks
==2591367== still reachable: 0 bytes in 0 blocks
==2591367== suppressed: 0 bytes in 0 blocks
==2591367==
==2591367== For lists of detected and suppressed errors, rerun with: -s
==2591367== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
valgrind noticed test_parse_sbat_section_too_many_elem() this wasn't
doing cleanup properly.
This changes it to clean up without respect to the results.
Before:
==2432919==
==2432919== HEAP SUMMARY:
==2432919== in use at exit: 365 bytes in 4 blocks
==2432919== total heap usage: 17 allocs, 13 frees, 2,310 bytes allocated
==2432919==
==2432919== 15 bytes in 1 blocks are definitely lost in loss record 1 of 4
==2432919== at 0x4845464: calloc (vg_replace_malloc.c:1117)
==2432919== by 0x401D21: UnknownInlinedFun (test-sbat.c:936)
==2432919== by 0x401D21: main (test-sbat.c:1042)
==2432919==
==2432919== 56 bytes in 1 blocks are definitely lost in loss record 2 of 4
==2432919== at 0x4845464: calloc (vg_replace_malloc.c:1117)
==2432919== by 0x402B1B: parse_sbat_var_data (sbat.c:234)
==2432919== by 0x40189C: UnknownInlinedFun (test-sbat.c:444)
==2432919== by 0x40189C: main (test-sbat.c:1028)
==2432919==
==2432919== 110 bytes in 1 blocks are definitely lost in loss record 3 of 4
==2432919== at 0x4845464: calloc (vg_replace_malloc.c:1117)
==2432919== by 0x402B1B: parse_sbat_var_data (sbat.c:234)
==2432919== by 0x401D67: UnknownInlinedFun (test-sbat.c:942)
==2432919== by 0x401D67: main (test-sbat.c:1042)
==2432919==
==2432919== 184 bytes in 1 blocks are definitely lost in loss record 4 of 4
==2432919== at 0x4845464: calloc (vg_replace_malloc.c:1117)
==2432919== by 0x402CD3: parse_sbat_section (sbat.c:56)
==2432919== by 0x4015A8: UnknownInlinedFun (test-sbat.c:323)
==2432919== by 0x4015A8: main (test-sbat.c:1019)
==2432919==
==2432919== LEAK SUMMARY:
==2432919== definitely lost: 365 bytes in 4 blocks
==2432919== indirectly lost: 0 bytes in 0 blocks
==2432919== possibly lost: 0 bytes in 0 blocks
==2432919== still reachable: 0 bytes in 0 blocks
==2432919== suppressed: 0 bytes in 0 blocks
==2432919==
==2432919== For lists of detected and suppressed errors, rerun with: -s
==2432919== ERROR SUMMARY: 4 errors from 4 contexts (suppressed: 0 from 0)
After:
==2525955==
==2525955== HEAP SUMMARY:
==2525955== in use at exit: 181 bytes in 3 blocks
==2525955== total heap usage: 17 allocs, 14 frees, 2,310 bytes allocated
==2525955==
==2525955== 15 bytes in 1 blocks are definitely lost in loss record 1 of 3
==2525955== at 0x4845464: calloc (vg_replace_malloc.c:1117)
==2525955== by 0x401D21: UnknownInlinedFun (test-sbat.c:937)
==2525955== by 0x401D21: main (test-sbat.c:1043)
==2525955==
==2525955== 56 bytes in 1 blocks are definitely lost in loss record 2 of 3
==2525955== at 0x4845464: calloc (vg_replace_malloc.c:1117)
==2525955== by 0x402ACB: parse_sbat_var_data (sbat.c:234)
==2525955== by 0x40189D: UnknownInlinedFun (test-sbat.c:445)
==2525955== by 0x40189D: main (test-sbat.c:1029)
==2525955==
==2525955== 110 bytes in 1 blocks are definitely lost in loss record 3 of 3
==2525955== at 0x4845464: calloc (vg_replace_malloc.c:1117)
==2525955== by 0x402ACB: parse_sbat_var_data (sbat.c:234)
==2525955== by 0x401D67: UnknownInlinedFun (test-sbat.c:943)
==2525955== by 0x401D67: main (test-sbat.c:1043)
==2525955==
==2525955== LEAK SUMMARY:
==2525955== definitely lost: 181 bytes in 3 blocks
==2525955== indirectly lost: 0 bytes in 0 blocks
==2525955== possibly lost: 0 bytes in 0 blocks
==2525955== still reachable: 0 bytes in 0 blocks
==2525955== suppressed: 0 bytes in 0 blocks
==2525955==
==2525955== For lists of detected and suppressed errors, rerun with: -s
==2525955== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 0 from 0)
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
If no TOPDIR is defined and a vendor sbat CSV is placed in
$(BUILDDIR)/data/sbat.*.csv, objcopy fails with the following
error.
objcopy --add-section .sbat=/shim/data/sbat.csv \
--set-section-flags .sbat=contents,alloc,load,readonly,data \
sbat_data.o
objcopy --add-section ".sbat.microsoft=sbat.microsoft.csv" sbat_data.o
objcopy --add-section ".sbat.microsoft=sbat.microsoft.csv" sbat_data.o
objcopy:stuf2iKG: can't add section '.sbat.microsoft': bad value
make: *** [Makefile:120: sbat_data.o] Error 1
The sbat.vendor.csv is getting included twice in VENDOR_SBATS.
Use sort to ensure unique entries in VENDOR_SBATS
Signed-off-by: Chris Co <chrco@microsoft.com>
|
|
Because a few shim builds were signed that did not properly initialize
the SBAT variable, and in doing so deleted valid SBAT variables, we need
to use a different name.
This changes the name from "SBAT" to "SbatLevel".
Signed-off-by: Jan Setje-Eilers <jan.setjeeilers@oracle.com>
|
|
Currently, the check for the contents of the SBAT variable has an
inverted strncmp() test, causing it to delete the variable
inappropriately.
This patch fixes that check, preventing shim from always stepping on the
sbat variable, and adds test cases to validate the correct logic.
Signed-off-by: Jan Setje-Eilers <jan.setjeeilers@oracle.com>
|
|
This moves the check for the SBAT variable's attributes and contents
into its own function, so that test cases can be written against it.
Signed-off-by: Jan Setje-Eilers <jan.setjeeilers@oracle.com>
|
|
Currently if you're building in a subdirectory, we're not correctly
finding vendor sbat.foo.csv files if they're in
$(TOPDIR)/data/sbat.foo.csv rather than $(BUILDDIR)/data/sbat.foo.csv.
This patch makes it search both of those during the build.
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
Signed-off-by: Peter Jones <pjones@redhat.com>
|
