On 28.01.21 12:00, Heinrich Schuchardt wrote:
On 28.01.21 09:20, Heinrich Schuchardt wrote:
On 1/28/21 1:57 AM, Tom Rini wrote:
On Thu, Jan 14, 2021 at 12:35:35PM -0800, Joel Peshkin wrote:
Add support for stack protector for UBOOT, SPL, and TPL as well as new pytest for stackprotector
Signed-off-by: Joel Peshkin joel.peshkin@broadcom.com Reviewed-by: Heinrich Schuchardt xypron.glpk@gmx.de
Oddly enough this cases a number of the TPM2 tests to fail on sandbox: https://dev.azure.com/u-boot/u-boot/_build/results?buildId=1706&view=log...
Thanks Tom for the head-up.
The problem is reproducible locally using 'make tests' with the patch applied on top of origin/master.
Best regards
Heinrich
The stack protector has successfully detected stack smashes. See below.
A secondary finding is: panic("foo") without \n is not correctly flushed to the console on the sandbox.
./test/py/test.py --bd=sandbox -ra --build-dir=build-sandbox -k='not test_stackprotector' shows no error for tpm2.
./test/py/test.py --bd=sandbox -ra --build-dir=build-sandbox -k='not test_stackprotector' shows the error for tpm2.
I think the test test_stackprotector() is broken. I causes the sandbox to reset but does not wait until reaches the prompt again, e.g add
u_boot_console.restart_uboot()
instead of assert(true).
@Joel Could you, please, submit a corrected patch.
@Takahiro For test/py/tests/test_efi_capsule/test_capsule_firmware.py I always see a smash. Could you, please, have a look at efi_launch_capsules().
Best regards
Heinrich
test_tpm2_init:
Stack smashing detected in function: 00005563faa7c521 relocated from 000000000004d521
u-boot.map 0x000000000004cf44 do_spi 0x000000000004d9e9 print_byte_string
It seems that the output written in the stack-protector test ends up in the following test which happens to be test_tpm2_init:
static int do_test_stackprot_fail(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[]) { 4d4db: 48 81 ec 98 00 00 00 sub $0x98,%rsp char a[128];
memset(a, 0xa5, 512); 4d4e2: ba 00 02 00 00 mov $0x200,%edx 4d4e7: be a5 00 00 00 mov $0xa5,%esi { 4d4ec: 64 48 8b 04 25 28 00 mov %fs:0x28,%rax 4d4f3: 00 00· 4d4f5: 48 89 84 24 88 00 00 mov %rax,0x88(%rsp) 4d4fc: 00· 4d4fd: 31 c0 xor %eax,%eax memset(a, 0xa5, 512); 4d4ff: 48 8d 7c 24 08 lea 0x8(%rsp),%rdi 4d504: e8 1f 34 0d 00 callq 120928 <memset> return 0; } 4d509: 48 8b 84 24 88 00 00 mov 0x88(%rsp),%rax 4d510: 00· 4d511: 64 48 2b 04 25 28 00 sub %fs:0x28,%rax 4d518: 00 00· 4d51a: 74 05 je 4d521 <do_test_stackprot_fail+0x46> 4d51c: e8 68 48 02 00 callq 71d89 <__stack_chk_fail>
4d521: 31 c0 xor %eax,%eax
4d523: 48 81 c4 98 00 00 00 add $0x98,%rsp 4d52a: c3 retq···
TestEfiCapsuleFirmwareFit.test_efi_capsule_fw3 #Stack smashing detected in function: 000055827c21cb58 relocated from 00000000000d8b58
Here we seem to have a real finding.
u-boot.map 0x00000000000d7fae efi_launch_capsules 0x00000000000da1ec set_shift_mask
efi_set_variable_int(L"CapsuleLast", &efi_guid_capsule_report, d8b10: 4c 8b 04 24 mov (%rsp),%r8 d8b14: 45 31 c9 xor %r9d,%r9d d8b17: 48 8d 35 42 1c 11 00 lea 0x111c42(%rip),%rsi # 1ea760 <efi_guid_capsule_report> d8b1e: b9 16 00 00 00 mov $0x16,%ecx d8b23: ba 07 00 00 80 mov $0x80000007,%edx d8b28: 48 8d 3d e7 61 0c 00 lea 0xc61e7(%rip),%rdi # 19ed16 <__func__.0+0x132e6> d8b2f: e8 34 ab 00 00 callq e3668 <efi_set_variable_int> return ret; d8b34: eb 0a jmp d8b40 <efi_launch_capsules+0xb92> return EFI_DEVICE_ERROR; d8b36: 49 bc 07 00 00 00 00 movabs $0x8000000000000007,%r12 d8b3d: 00 00 80· } d8b40: 48 8b 84 24 c8 00 00 mov 0xc8(%rsp),%rax d8b47: 00· d8b48: 64 48 2b 04 25 28 00 sub %fs:0x28,%rax d8b4f: 00 00· d8b51: 74 05 je d8b58 <efi_launch_capsules+0xbaa> d8b53: e8 31 92 f9 ff callq 71d89 <__stack_chk_fail>
d8b58: 48 81 c4 d8 00 00 00 add $0xd8,%rsp
d8b5f: 4c 89 e0 mov %r12,%rax d8b62: 5b pop %rbx d8b63: 5d pop %rbp d8b64: 41 5c pop %r12 d8b66: 41 5d pop %r13 d8b68: 41 5e pop %r14 d8b6a: 41 5f pop %r15 d8b6c: c3 retq···
Best regards
Heinrich