| Age | Commit message (Collapse) | Author |
|---|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
Note the one test case I'm not 100% sure about. Someone let me know.
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
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>
|
|
[currently #if 0'd to oblivion by pjones]
Signed-off-by: Chris Co <chrco@microsoft.com>
|
