On July 23, 2021 9:35 PM, Lendacky, Thomas wrote:
On 7/22/21 5:58 PM, Xu, Min M wrote:
On July 23, 2021 1:08 AM, Tom Lendacky wrote:unlikely, though).
On 7/22/21 12:52 AM, Min Xu wrote:
RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3429Is the memory area guaranteed to be zeroed for legacy guests?
diff --git a/OvmfPkg/ResetVector/Ia32/Flat32ToFlat64.asm
index c6d0d898bcd1..2206ca719593 100644
@@ -17,6 +17,9 @@ Transition32FlatTo64Flat:
+ cmp dword[TDX_WORK_AREA], 0x47584454 ; 'TDXG'
+ jz TdxTransition32FlatTo64Flat
Hopefully, this won't trip up a non-TDX guest with a false match (highly
TDX_WORK_AREA is piece of TdxMailbox which is located in the MEMFDguest or not.
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-
Since Tdx re-use the memory region (PcdOvmfSecGhcbBackupBase) as theI believe PcdOvmfSecGhcbBackupBase can be cleared early. For SEV-ES, it isn't
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?
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.
Thanks Tom. I will update it in the next version.