Quantcast
Channel: VMware Communities : All Content - All Communities
Viewing all articles
Browse latest Browse all 175326

UEFI Runtime Services Bug

$
0
0

Fusion Pro 11.5.1 on MAC Host

 

UEFI provides a number of "Boot Services" and "Runtime Services".   Boot Services are used in the pre-boot environment via physical addressing, while Runtime Services are available in both the pre-boot and post-boot environments.   The transition between these phases of operation occurs with a call to the Boot Service "ExitBootServices" followed by a call to another Boot Service "SetVirtualAddressMap".    Once these two procedures have been called, the "Boot Services" dispatch table is to be zeroed out, along with the UEFI System Table's pointer to the Boot Services table.   No further Boot Services should be called.

 

After calling SetVirtualAddressMap, the UEFI Runtime Services can be called from the virtual addresses supplied in the memory map argument passed to SetVirtualAddressMap.

UEFI updates its Runtime Service dispatch table to include these virtual addresses and notifications are issued to any UEFI components and drivers that need to know that we have switched to a runtime environment.

 

That's how it *should* work...

 

However, what is happening is that Fusion's UEFI implementation is incorrectly handling Runtime Service calls.   To illustrate these, I am calling a Runtime Service "GetTime" using its physical address BEFORE ExitBootServices.   This works fine, however, I have noticed by stepping through the code that Fusion has set up the "Boot" Services table (identified by it's ASCII signature) to contain the Runtime Service vectors.   How do I know?   Like I said, each table has an ASCII signature, in this case "BOOT_SERV", yet stepping through the code shows that it is correctly pulling the procedure pointer for GetTime from the expected position in a Runtime Services table.   Strange.

 

Now AFTER calling ExitBootServices and SetVirtualAddressMap, the Runtime Service call to GetTime is made again using its Virtual Address.   It fails.

Stepping through the code again, the code again tries to get the GetTime procedure from the "Boot" Service table but it has now been zeroed out! 

 

When I examine the EFI_SYSTEM_TABLE's pointer to the Boot Services table, it is correctly zero.

When I examine the EFI_SYSTEM_TABLE's pointer to the Runtime Services table, it is correct and each of the entries in the table is correct.  But the actual Runtime call to GetTime is still trying to access the Boot Services table.    This is clearly a bug in Fusions implementation of UEFI.   I will try this on both Workstation and ESXi shortly.   BTW, I have decades of experience with EFI/UEFI and OS Loaders and my code is running on hundreds of systems and other VM Hosts, so this is not a post from a confused newbie....  Just sayin'   ;^)

 

Has anyone else actually used UEFI Runtime Services in the post-boot, virtual environment?


Viewing all articles
Browse latest Browse all 175326

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>