Re: [PATCH V2 4/4] OvmfPkg/ResetVector: Update ResetVector to support Tdx

Lendacky, Thomas

On 7/22/21 5:58 PM, Xu, Min M wrote:
On July 23, 2021 1:08 AM, Tom Lendacky wrote:
On 7/22/21 12:52 AM, Min Xu wrote:

diff --git a/OvmfPkg/ResetVector/Ia32/Flat32ToFlat64.asm
index c6d0d898bcd1..2206ca719593 100644
--- a/OvmfPkg/ResetVector/Ia32/Flat32ToFlat64.asm
+++ b/OvmfPkg/ResetVector/Ia32/Flat32ToFlat64.asm
@@ -17,6 +17,9 @@ Transition32FlatTo64Flat:

OneTimeCall SetCr3ForPageTables64

+ cmp dword[TDX_WORK_AREA], 0x47584454 ; 'TDXG'
+ jz TdxTransition32FlatTo64Flat
Is the memory area guaranteed to be zeroed for legacy guests? Hopefully,
this won't trip up a non-TDX guest with a false match (highly unlikely, though).
TDX_WORK_AREA is piece of TdxMailbox which is located in the MEMFD started
from PcdOvmfSecGhcbBackupBase. In Td guest, this memory region is initialized
to all-0 by host VMM. In legacy guests, I am not sure what's the initialized value
it is. So 'TDXG' is checked to guarantee it is Td-guest or not.
Since Tdx re-use the memory region (PcdOvmfSecGhcbBackupBase) as the
TDX_WORK_AREA, and @Tom Lendacky you should be the original owner of
PcdOvmfSecGhcbBackupBase, can this area be cleared in the beginning of
ResetVector in legacy guests? Or I should better create a TDX specific work
area in MEMFD to guarantee the Td And Non-Td check?
I believe PcdOvmfSecGhcbBackupBase can be cleared early. For SEV-ES, it
isn't shared with the hypervisor, so clearing it before activating the
pagetables can be done (it will be treated as encrypted before paging is
enabled and mapped as encrypted after paging is enabled) and for a legacy
guest the mapping doesn't matter. It isn't required to be cleared today,
so if you do add something, be sure to put a comment in there about why
it's being done. No need for a new area.

The possibility of random data being there that matches 'TDXG' is
extremely low. But better safe than sorry, I guess.


Join to automatically receive all group messages.