Dasharo
Efibootmgr returns `Bad address` on FreeBSD on Protectli V1410
Component
Dasharo firmware
Device
other
Dasharo version
v0.9.3-rc1
Dasharo Tools Suite version
No response
Test case ID
No response
Brief summary
Efibootmgr returns Bad address
How reproducible
100%
How to reproduce
Try to run efibootmgr or efivars
Expected behavior
Efibootmgr should show the boot options, efivars should enable reading and setting of efi variables
Actual behavior
Any use case results in a Bad address error:
$ efibootmgr
efibootmgr: efi_get_variable: Bad address
$ efivar -n 8be4df61-93ca-11d2-aa0d-00e098032b8c-SecureBoot -p
efivar: fetching 8be4df61-93ca-11d2-aa0d-00e098032b8c-SecureBoot: Bad address
Screenshots
No response
Additional context
There's already been some discussion related to this matter in this PR
Solutions you've tried
No response
The issue described in the referenced comment should have been fixed, but maybe there is a similar different one. Was EFI vars in FreeBSD working fine on the previous firmware release?
Update: although report about Nova Custom V56 does look very similar, so maybe the fix is missing something.
Something is wrong here. According to https://github.com/Dasharo/coreboot/blob/baa4d109ad23d66c36ce91fd0bf23f3d3c52b45a/configs/config.protectli_vault_jsl_v1410#L30, V1410 doesn't use rebased branch of EDK. If you intended to test release candidate, that's not what you're testing.
As for the problem, it was a different manifestation of the same issue because I fixed only part of it.
Something is wrong here. According to https://github.com/Dasharo/coreboot/blob/baa4d109ad23d66c36ce91fd0bf23f3d3c52b45a/configs/config.protectli_vault_jsl_v1410#L30, V1410 doesn't use
rebasedbranch of EDK. If you intended to test release candidate, that's not what you're testing.As for the problem, it was a different manifestation of the same issue because I fixed only part of it.
That's the exact problem. The non-rebased EDK2 also has problems and it seems to use BS somewhere at runtime... It also manifested on VP2410 (and possibly others...) on non-rebased EDK2
That's the exact problem.
Mind that these issues on rebased are related to MbedTLS which wasn't part of EDK2 before the rebase. Maybe OpenSSL wrapper has/had similar issues.
We're after another rebase, maybe it's worth checking if the issue is fixed now, on the latest codebases?
It should have been completely fixed in version on top of 2024.02, I just didn't find all places where boot services were accessed at first. 2025.02 version of Dasharo EDK has the same commits with fixes as 2024.02, upstream didn't change much in that code.
Tested on FW built from 6146be5f0ad0f8c63c1b07dce5e6df88207a69d5 of dasharo/coreboot. Issue still present.
The issue is not hardware-specific and can be reproduced in QEMU. You'll get it every time FreeBSD or something else enforces alignment checks and calls into EFI RT services with a stack aligned to 16 bytes (8 bytes alignment may actaully hide the error). Full error:
Fatal trap 9: general protection fault while in kernel mode
cpuid = 0; apic id = 00
instruction pointer = 0x20:0x7f4f80c4
stack pointer = 0x28:0xfffffe0085b61958
frame pointer = 0x28:0xfffffe0085b61a98
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags = trace trap, interrupt enabled, resume, IOPL = 0
current process = 946 (efibootmgr)
rdi: fffffe0085b61b38 rsi: fffff80002c1b520 rdx: fffffe0085b61d60
rcx: fffff80002707a00 r8: fffffe0085b61d70 r9: fffffe0085b61d80
rax: 000000007f4f8000 rbx: 0000000000000000 rbp: fffffe0085b61a98
r10: 0000003000300030 r11: fffff80002c1b520 r12: fffffe0085b61c58
r13: fffffe0085b61d60 r14: fffffe0090e14000 r15: fffff80002707a00
trap number = 9
EFI RT fault general protection fault
efibootmgr: efi_get_variable: Bad address
Here's where it fails:
0x7f4f809e <VariableServiceGetVariable> push %rbp
0x7f4f809f <VariableServiceGetVariable+1> mov %rsp,%rbp
0x7f4f80a2 <VariableServiceGetVariable+4> push %r15
0x7f4f80a4 <VariableServiceGetVariable+6> push %r14
0x7f4f80a6 <VariableServiceGetVariable+8> push %r13
0x7f4f80a8 <VariableServiceGetVariable+10> mov %rdx,%r13
0x7f4f80ab <VariableServiceGetVariable+13> push %r12
0x7f4f80ad <VariableServiceGetVariable+15> push %rdi
0x7f4f80ae <VariableServiceGetVariable+16> push %rsi
0x7f4f80af <VariableServiceGetVariable+17> push %rbx
0x7f4f80b0 <VariableServiceGetVariable+18> sub $0x108,%rsp
0x7f4f80b7 <VariableServiceGetVariable+25> test %rdx,%rdx
0x7f4f80ba <VariableServiceGetVariable+28> mov %r8,0x20(%rbp)
0x7f4f80be <VariableServiceGetVariable+32> sete %al
0x7f4f80c1 <VariableServiceGetVariable+35> test %r9,%r9
H+>0x7f4f80c4 <VariableServiceGetVariable+38> movaps %xmm6,0x60(%rsp)
0x7f4f80c9 <VariableServiceGetVariable+43> sete %dl
0x7f4f80cc <VariableServiceGetVariable+46> movaps %xmm7,0x70(%rsp)
0x7f4f80d1 <VariableServiceGetVariable+51> or %dl,%al
If %rsp is 16 bytes aligned at first, it won't be after push %rbp. Then after mov %rsp,%rbp both %rsp and %rbp are 8 bytes aligned. Seven 64-bit pushes + sub $0x108,%rsp maintain misaligned stack and movaps results in an interrupt from the CPU.
Closing as fixed by https://github.com/Dasharo/edk2/pull/278 and https://github.com/Dasharo/coreboot/pull/782