efibootguard on qemux86_64 fails with emulation error

[Maxime Roussin-Bélanger]

Hi,

We're encountering an issue with efibootguard failing to start with the poky nanbield branch, which works fine on the mickledore branch using the qemux86_64 machine.

```

KVM internal error. Suberror: 1
extra data[0]: 0x0000000000000000
extra data[1]: 0x0000000000000400
extra data[2]: 0x0000000100000014
extra data[3]: 0x00000000000b0000
extra data[4]: 0x0000000000000000
extra data[5]: 0x0000000000000000
emulation failure
RAX=0000000000000038 RBX=000000007e070b30 RCX=000000007ee18bc0 RDX=0000000000000000
RSI=0000000000000000 RDI=000000007fe978b0 RBP=000000007e725a98 RSP=000000007fe97ab8
R8 =0000000000000004 R9 =0000000000000000 R10=000000007e088a98 R11=0000000000000002
R12=000000007f5ec018 R13=000000007e072048 R14=0000000000000000 R15=000000007eb481c0
RIP=00000000000b0000 RFL=00000a96 [-OS-AP-] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0030 0000000000000000 ffffffff 00c09300 DPL=0 DS   [-WA]
CS =0038 0000000000000000 ffffffff 00a09b00 DPL=0 CS64 [-RA]
SS =0030 0000000000000000 ffffffff 00c09300 DPL=0 DS   [-WA]
DS =0030 0000000000000000 ffffffff 00c09300 DPL=0 DS   [-WA]
FS =0030 0000000000000000 ffffffff 00c09300 DPL=0 DS   [-WA]
GS =0030 0000000000000000 ffffffff 00c09300 DPL=0 DS   [-WA]
LDT=0000 0000000000000000 0000ffff 00008200 DPL=0 LDT
TR =0000 0000000000000000 0000ffff 00008b00 DPL=0 TSS64-busy
GDT=     000000007f5dc000 00000047
IDT=     000000007f245018 00000fff
CR0=80010033 CR2=0000000000000000 CR3=000000007f801000 CR4=00000668
DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000
DR6=00000000ffff0ff0 DR7=0000000000000400
EFER=0000000000000d00
Code=00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <ff> ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

```

This issue is similar to https://github.com/systemd/systemd/issues/11541 but the efibootguard makefile seems to be correct and complete.
Debugging reveals the crash happens at the exit of `InitializeLib(this_image, system_table);` So probably something about the return address?
Stepping through the code shows gnu-efi functioning normally, but we cannot obtain the ImageBase address, preventing proper library loading, with add-symbol-file. 

We'd appreciate any pointers on how to debug this issue further.

Max.

[Jan Kiszka]

Which QEMU and kernel versions are we talking about, which efibootguard
commit?

Jan

--
Siemens AG, Technology
Linux Expert Center

[Maxime Roussin-Bélanger]

QEMU 8.2.1 and efibootguard v0.16.

Host is running a 6.1 kernel

qemu is trying to start a 6.2 kernel, but never reaches it.

Max

[Maxime Roussin-Bélanger]

I would like to add that we were using gnu-efi 3.0.17, and by downgrading it to 3.0.15, it now works.

That probably means that gnu-efi is the culprit here.

Max.

[Jan Kiszka]

On 08.03.24 16:18, Maxime Roussin-Bélanger wrote:
>
>
> On Thu, Mar 7, 2024 at 2:48 AM Maxime Roussin-Bélanger
> <maxime.rous...@gmail.com

Christian is looking into that topic, you may have seen some patches of
him on the list. He told me that there is currently no sane release of
gnu-efi if you go beyond current distro versions.

[Storm, Christian]

Hi,

>> I would like to add that we were using gnu-efi 3.0.17, and by
>> downgrading it to 3.0.15, it now works.
>>
>> That probably means that gnu-efi is the culprit here.
>>
>
> Christian is looking into that topic, you may have seen some patches of
> him on the list. He told me that there is currently no sane release of
> gnu-efi if you go beyond current distro versions.

Indeed, gnu-efi version 3.0.15 is the latest version release-tagged EFI Boot Guard currently works with, nothing beyond. You need at least the patch [1] since with gnu-efi 3.0.16 commit 4f8b339 "Make ELF constructors and destructors work", EFI Boot Guard's .init_array method no longer works as the watchdog probing functions are not suitable for being called as constructors. That's most likely the reason for your crash.
Probably, you need [2] as well if you leave the default -Werror enabled and use gnu-efi > 3.0.17.

On x86 at least, then, it should work since it uses --target=efi-app-$(ARCH).
On ARM64, it depends on the binutils version (>= 2.38 or not), see my patch "Fix arm support for gnu-efi > 3.0.15", posted to the mailing list but not yet merged.

That said, I have not yet tested whether you strictly need some commits 3.0.17..HEAD under the various scenarios, e.g., signed, but there are some sensible fixes to linker scripts and crt0 in that range...


Kind regards,
Christian

[1] https://github.com/siemens/efibootguard/commit/ee11bc14c7289f4875a9db4e5b078f162e0fe042
[2] https://github.com/siemens/efibootguard/commit/115fa35721592a6e91cc2d771c860ed3fb6ec64b
[3] https://github.com/siemens/efibootguard/blob/master/Makefile.am#L246


--
Dr. Christian Storm
Siemens AG, Technology, T CED OES-DE
Otto-Hahn-Ring 6, 81739 Munich, Germany