x64 General Protection Fault in Blog

[Knight-Ops]

Walking through https://medium.com/@gil0mendes/an-efi-app-a-bit-rusty-82c36b745f49, it seems that the API has changed, but the old API doesn't throw any type errors and compiles fine. When I go through and run within QEMU I get :
!!!! X64 Exception Type - 0D(#GP - General Protection) CPU Apic ID - 00000000 !!!! ExceptionData - 0000000000000000 RIP - 00000000057EE99C, CS - 0000000000000038, RFLAGS - 0000000000000206 RAX - 5453595320494249, RCX - 0000000007BEE018, RDX - 0000000007BEE000 RBX - 0000000007200498, RSP - 0000000007F0C3E0, RBP - 0000000007F0C5A8 RSI - 0000000000000009, RDI - 0000000007200498 R8 - 0000000000000000, R9 - 0000000007200318, R10 - 0000000007276098 R11 - 000000000000000A, R12 - 0000000000000000, R13 - 0000000007200B18 R14 - 0000000000000000, R15 - 0000000006504598 DS - 0000000000000030, ES - 0000000000000030, FS - 0000000000000030 GS - 0000000000000030, SS - 0000000000000030 CR0 - 0000000080010033, CR2 - 0000000000000000, CR3 - 0000000007C01000 CR4 - 0000000000000668, CR8 - 0000000000000000 DR0 - 0000000000000000, DR1 - 0000000000000000, DR2 - 0000000000000000 DR3 - 0000000000000000, DR6 - 00000000FFFF0FF0, DR7 - 0000000000000400 GDTR - 0000000007BEE698 0000000000000047, LDTR - 0000000000000000 IDTR - 00000000076F1018 0000000000000FFF, TR - 0000000000000000 FXSAVE_STATE - 0000000007F0C040 !!!! Find image based on IP(0x57EE99C) (snip) (ImageBase=00000000057EB000, EntryPoint=00000000057EC000) !!!!

This seems to stem from the uefi_services::init. Essentially it boils down to trying to dereference RAX which is obviously ASCII, but there doesn't seem to be cross references to the offending function. I didn't dive too deep down the rabbit hole beyond that. I swapped everything over to the new API seen in the test-runner and it also compiles file, but this actually works without faulting. I haven't hunted down where the actual issue is, but thought it might be useful to either re-document or maybe even add a macro that will enforce the new API.

[GabrielMajeri]

I've tried reproducing your issue by copy and pasting the code from that article, then making it compile by using the new API. But it does not crash for me at any point. Could you provide the code that reproduces the issue as a gist and specify how you are running QEMU?

[Knight-Ops]

Gist : https://gist.github.com/r0ck3tAKATrashPanda/f0b7262140b17a2d09167c40209cc477

OVMF : https://www.kraxel.org/repos/jenkins/edk2/edk2.git-ovmf-x64-0-20190704.1245.g82c1a21208.noarch.rpm

QEMU : .\qemu-system-x86_64.exe -nodefaults -vga std -machine q35,accel=kvm:tcg -m 128M -drive if=pflash,format=raw,readonly=on,file=OVMF-pure-efi.fd -drive if=pflash,format=raw,readonly=on,file=OVMF_VARS-pure-efi.fd -drive format=raw,file=fat:rw:vmdir -serial stdio -monitor vc:1024x768

Edit: This is also on a Windows system (for QEMU)

[GabrielMajeri]

I see what the issue is. The uefi_start function receives a reference to SystemTable<Boot> instead of taking it by value and this crashes the program (since this type is already just a wrapper for the system table).

Unfortunately I'm not entirely sure if we can fix this since the Rust compilers allows the efi_main function to have any signature. We have docs on how it should look, but without using a macro with custom derive or something like that it's unlinkely we'll be able to verifiy the signature of the function.

[Knight-Ops]

Is there any issue with the macro route? Personally I would rather be able to label efi_main instead of necessarily tying it to a specific function naming scheme, and would definitely benefit from type checking just to be sure.

…

On Wed, Sep 18, 2019, 12:28 AM Gabriel Majeri ***@***.***> wrote: I see what the issue is. The uefi_start function receives a reference to SystemTable<Boot> instead of taking it by value and this crashes the program (since this type is already just a wrapper for the system table). Unfortunately I'm not entirely sure if we can fix this since the Rust compilers allows the efi_main function to have any signature. We have docs <https://github.com/rust-osdev/uefi-rs/blob/master/BUILDING.md#steps> on how it should look, but without using a macro with custom derive or something like that it's unlinkely we'll be able to verifiy the signature of the function. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#99?email_source=notifications&email_token=AEF5PNNEPTF2FTGW37TPT2LQKGU7BA5CNFSM4IXIZVY2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD66YDJQ#issuecomment-532513190>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEF5PNINXWICAHGJ4NUQY7LQKGU7BANCNFSM4IXIZVYQ> .

[GabrielMajeri]

There's no issue in particular, but I've been busy recently and need some time to think how to implement a macro-based solution (probably a custom attribute implemented in uefi-macros). I'll close this issue and track this in #100