efi-boot-shim.git, branch 15.4

Update version to 15.4

2021-03-30T20:55:03+00:00

Mark this officially as shim 15.4 Signed-off-by: Peter Jones

Fix an off-by-one on the sbat self-check.

2021-03-30T15:40:32+00:00

Signed-off-by: Peter Jones

arm/aa64 targets: put .rel* and .dyn* in .rodata

2021-03-30T15:40:32+00:00

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

sbat: add more dprint()

2021-03-30T15:40:32+00:00

This adds dprint() to a bunch of our error returns. Signed-off-by: Peter Jones

Fix openssl's 'make clean'

2021-03-29T14:37:05+00:00

test_verify_sbat_null_sbat_section(): call cleanup_sbat_var()

2021-03-28T17:20:04+00:00

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

parse_sbat_var_data()/cleanup_sbat_var(): fix free logic

2021-03-28T17:20:04+00:00

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

test_parse_sbat_section_too_many_elem(): free section entries

2021-03-28T17:20:04+00:00

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

Makefile: sort vendor sbats to remove duplicates

2021-03-28T17:19:53+00:00

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

Change SBAT variable name to SbatLevel

2021-03-27T22:48:04+00:00

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