Page 1 of 1
VirtualBox 6.1.x EFI bug
Posted: Mon Apr 20, 2020 11:07 am
by 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.
Re: VirtualBox 6.1.x EFI bug
Posted: Mon Apr 20, 2020 2:50 pm
by 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.
Re: VirtualBox 6.1.x EFI bug
Posted: Mon Apr 20, 2020 9:57 pm
by 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.
Re: VirtualBox 6.1.x EFI bug
Posted: Tue Apr 21, 2020 2:13 am
by Octocontrabass
zhiayang wrote: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.
zhiayang wrote: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.
Re: VirtualBox 6.1.x EFI bug
Posted: Tue Apr 21, 2020 9:59 am
by 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])...
Re: VirtualBox 6.1.x EFI bug
Posted: Tue Apr 21, 2020 10:50 pm
by 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.
Re: VirtualBox 6.1.x EFI bug
Posted: Wed Apr 22, 2020 3:17 am
by Octocontrabass
zhiayang wrote: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.
Re: VirtualBox 6.1.x EFI bug
Posted: Wed Apr 22, 2020 8:21 am
by 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!