VirtualBox 6.1.x EFI bug

[zhiayang]

VBox forums don't seem to be receptive to this, so I'm posting here on my good friend the OSDev forums. Basically the situation is this:

1. Updated to virtualbox 6.1
2. EFI bootloader dies when ExitBootServices is called.
3. panik
4. find this entry in the wiki's UEFI page: https://wiki.osdev.org/UEFI#My_bootload ... YPE_values
5. OMG, it's exactly my problem (it hangs, but also prints a debug message to serial indicating a page fault)
6. Test by not using EfiMemoryType values > 0x80000000 (though this means my kernel won't startup correctly, it is fine if it gets loaded and jumped to)
7. it works!
8. See changelog of Virtualbox; 6.1.0 mentions EFI update
9. downgrade to 6.0.20; problem is gone?!
10. Made a post on VBox forums asking what's going on
11. moderator starts pointing fingers at why I only have 128MB ram, or 5MB display memory, or "Other 64-bit" as guest OS

I'd appreciate it if someone can verify this? I hope I'm not going crazy.

[Octocontrabass]

You're correct, it's a firmware bug. The bug mentioned on the wiki was fixed a while ago, so it's a new bug with very similar symptoms.

I don't have DxeCore.pdb for the OVMF binary included in VirtualBox, nor do I have the tools to build OVMF myself. However, I was able to track it down to a signed comparison against EfiMaxMemoryType that should be unsigned. The code in question looks pretty similar to that bugfix patch in Page.c, but as far as I can tell, MemoryMap->Type is unsigned.

[zhiayang]

Ah, that's reassuring (i guess...?). I don't suppose anyone has filed this bug report to VBox? They're also using OVMF-derived images right? So I'm guessing that the bug was introduced somewhere after october 2019, but fixed some time before april 2020, because both of these versions of OVMF that I tried on QEMU don't exhibit this bug.

[Octocontrabass]

I don't suppose anyone has filed this bug report to VBox?

I haven't, but I didn't check to see if anyone else did.

They're also using OVMF-derived images right?

Yes, but I'm not sure how similar it is to plain OVMF. It could potentially be a bug that only affects VirtualBox due to some difference in the code or the build process.

[zhiayang]

Ah, okay. I did try searching a bit for open issues, but didn't find anything. How did you end up tracing the bug? I'm guessing they did a "foo < MaxMemoryType" which would be true since the MSB is set (and enums are signed by default right? [unless the values exceed int representation])...

[kzinti]

The same bug exists with the firmware on my machine (Asus Hero Maximus VI). Many other real machines have the problem. This means you can't use custom memory types (yes it sucks). I did find some UEFI source code (Tianocore/OVMF? not sure) that basically does array indexing using the memory type value when you call GetMemoryMap(). Of course the array doesn't have >= 0x80000000 entries and the call will crash your machine.

I have found a few other issues with UEFI and documented them here: https://github.com/kiznit/rainbow-os/bl ... /README.md.

I am sure there are other problems I haven't encountered or heard of yet... Feel free to bring them up and I can update my list.

[Octocontrabass]

How did you end up tracing the bug?

I extracted DxeCore.efi from the firmware image and disassembled the code near the point where your log says the page fault occurs.

Code: Select all

.text:0000000007238BBB loc_7238BBB:
.text:0000000007238BBB                 cmp     rdx, r8
.text:0000000007238BBE                 jz      short loc_7238C01
.text:0000000007238BC0                 cmp     dword ptr [rdx+14h], 0Fh
.text:0000000007238BC4                 jge     short loc_7238BF2         <-- signed comparison
.text:0000000007238BC6                 movsxd  rax, dword ptr [rdx+14h]
.text:0000000007238BCA                 lea     rcx, [rax+rax*2]
.text:0000000007238BCE                 lea     rax, unk_724D709
.text:0000000007238BD5                 add     rcx, rcx
.text:0000000007238BD8                 cmp     [rax+rcx*8], dil          <-- page fault here
.text:0000000007238BDC                 jz      short loc_7238BF2
.text:0000000007238BDE                 mov     eax, [rdx+18h]
.text:0000000007238BE1                 test    rbp, rax
.text:0000000007238BE4                 jnz     short loc_7238BF7
.text:0000000007238BE6                 mov     rax, [rdx+20h]
.text:0000000007238BEA                 inc     rax
.text:0000000007238BED                 test    rbp, rax
.text:0000000007238BF0                 jnz     short loc_7238BF7
.text:0000000007238BF2
.text:0000000007238BF2 loc_7238BF2:
.text:0000000007238BF2
.text:0000000007238BF2                 mov     rdx, [rdx]
.text:0000000007238BF5                 jmp     short loc_7238BBB

Now that I'm looking at it again, this looks an awful lot like CoreTerminateMemoryMap(), and Entry->Type just happens to be an EFI_MEMORY_TYPE enum. I spotted a few other comparisons between EFI_MEMORY_TYPE enum variables and EfiMaxMemoryType, which implies the existence of further bugs related to user-defined memory types.

[zhiayang]

Oh man. Looks like my bootloader will have to do some extra work to tell the kernel about memory regions without being able to do this...

Thanks @kzinti as well for highlighting the other bugs!