summaryrefslogtreecommitdiff
path: root/test-sbat.c
AgeCommit message (Collapse)Author
2025-02-05Generate and use generated_sbat_var_defs.hJan Setje-Eilers
Build changes to generate include/generated_sbat_var_defs.h from SbatLevel_Variable.txt and use that header file. From here on forward SbatLevel_Variable.txt should be the only place a new revocation needs to be recorded. Signed-off-by: Jan Setje-Eilers <Jan.SetjeEilers@oracle.com>
2024-01-22Rename "previous" revocations to "automatic"Jan Setje-Eilers
When the term previous was introduced for revocations to be automatically applied there was a hope that everytime a new revocation was built into shim, the previous revocation could be applied automatically. Further experience has shown the real world to be more complex than that. The automatic payload will realistically contain a set of revocations governed by both the cadence at which a distro's customer base updates as well as the severity of the issue being revoked. This is not a functional change. Signed-off-by: Jan Setje-Eilers <Jan.SetjeEilers@oracle.com>
2023-12-05shim should not self revokeJan Setje-Eilers
Before applying an updated SbatLevel shim should re-run introspection and never apply a revocation level that would prevent the currently running shim from booting. The proper way forward is to update shim first. Signed-off-by: Jan Setje-Eilers <Jan.SetjeEilers@oracle.com>
2023-12-05Allow SbatLevel data from external binaryJan Setje-Eilers
Ingest SBAT Levels from revocations binary thereby allowing level requirements to be updated independently from shipping a new shim. Do not automatically apply any revocations from a stock shim at this point. Signed-off-by: Jan Setje-Eilers <Jan.SetjeEilers@oracle.com>
2023-06-29Fix a 1-byte memory leak in .sbat parsing.Peter Jones
On the occasion that .sbat is entirely made of characters that aren't meaningfully CSV /data/, but which the parser accepts (i.e. newline), we currently allocate a byte of memory which then gets leaked. This patch tests for that condition and skips the allocation when there aren't any actual /entries/ to parse. Signed-off-by: Peter Jones <pjones@redhat.com>
2023-05-02test-sbat: Fix exit codeNicholas Bishop
Fix the `main` function in `test-sbat.c` to return the `status` variable like the other `test-*.c` files. Signed-off-by: Nicholas Bishop <nicholasbishop@google.com>
2022-12-07Make sbat_var.S parse right with buggy gcc/binutilsPeter Jones
In https://github.com/rhboot/shim/issues/533 , iokomin noticed that gas in binutils before 2.36 appears to be incorrectly concatenating string literals in '.asciz' directives, including an extra NUL character in between the strings, and this will cause us to incorrectly parse the .sbatlevel section in shim binaries. This patch adds test cases that will cause the build to fail if this has happened, as well as changing sbat_var.S to to use '.ascii' and '.byte' to construct the data, rather than using '.asciz'. Signed-off-by: Peter Jones <pjones@redhat.com>
2022-05-23Fix preserve_sbat_uefi_variable() logicJan Setje-Eilers
preserve_sbat_uefi_variable() shoud really deal with the sbat metadata version as a numerical value that could gain more digits. It also needs to only compare the datestamp since the actual metadata can grow and shrink Signed-off-by: Jan Setje-Eilers <Jan.SetjeEilers@oracle.com>
2022-05-17SBAT revocation managementJan Setje-Eilers
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>
2021-03-28test_verify_sbat_null_sbat_section(): call cleanup_sbat_var()Peter Jones
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>
2021-03-28parse_sbat_var_data()/cleanup_sbat_var(): fix free logicPeter Jones
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>
2021-03-28test_parse_sbat_section_too_many_elem(): free section entriesPeter Jones
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>
2021-03-27Fix SBAT variable content validation.Jan Setje-Eilers
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>
2021-03-10Add some test cases, and make "make test" actually work.Peter Jones
Note the one test case I'm not 100% sure about. Someone let me know. Signed-off-by: Peter Jones <pjones@redhat.com>
2021-02-25Fix-up and enable a bunch of .sbat section parsing tests.Peter Jones
This brings all the tests Chris Co wrote about parsing the .sbat section back. Some of the actual test functions became redundant, and some new ones were needed, but all of the actual test cases should be represented here. Note that building and running this test does not quite work yet /on this branch/. In order to do that, we need some cleanups and reorganizing that I don't want to push just yet, which can be found on https://github.com/rhboot/shim/tree/test-reorg Signed-off-by: Peter Jones <pjones@redhat.com>
2021-02-25Add initial sbat unit testing codeChris Co
[currently #if 0'd to oblivion by pjones] Signed-off-by: Chris Co <chrco@microsoft.com>
generated by cgit v1.2.3 (git 2.39.1) at 2025-08-23 21:45:09 +0000