[edk2-devel] [PATCH V3 06/10] OvmfPkg: Add AmdSev.asm in ResetVector

[Min Xu]

On July 27, 2021 8:46 PM, Yao, Jiewen wrote:
> HI Min
> I agree with Brijesh.
> 
> The basic rule is: SEV file shall never refer to TDX data structure. TDX file
> shall never refer to SEV data structure.
> These code should be isolated clearly.
> 
> Do we still need that logic if we follow the new pattern?
I have replied to Brijesh's mail about the concern of the new pattern. 

I have some concern in the current pattern:
====================
	OneTimeCall   PreMainFunctionHookSev
	OneTimeCall   PreMainFunctionHookTdx
MainFunction:
	XXXXXX
	OneTimeCall   PostMainFunctionHookSev
	OneTimeCall   PostMainFunctionHookTdx
====================
The TEE function need implement a TEE check function (such as IsSev, or IsTdx). 

Tdx call CPUID(0x21) to determine if it is tdx guest in the very beginning of ResetVector. Then 'TDXG' is set
in TDX_WORK_AREA. SEV does the similar work which call CheckSevFeatures to set SEV_ES_WORK_AREA to 1.

After that both TDX and SEV read the above WORK_AREA to check if it is TDX or SEV or legacy guest.

In Tdx the access to SEV_ES_WORK_AREA will trigger error because SEV_ES_WORK_AREA is *NOT* initialized by host VMM.
In SEV-SNP I am afraid the access to TDX_WORK_AREA will trigger error too.

I am wondering if TDX and SEV can use the same memory region (for example, TEE_WORK_AREA) as the work area?
So that this work area is guaranteed to be initialized in both TDX and SEV. Structure of the TEE_WORK_AREA may
look like this:
  typedef struct {
      UINT8  Flag[4];         'TDXG' or 'SEVG' or all-0
      UINT8  Others[];
  } TEE_WORK_AREA;
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#78262): https://edk2.groups.io/g/devel/message/78262
Mute This Topic: https://groups.io/mt/84476064/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [edk2-devel-archive at redhat.com]
-=-=-=-=-=-=-=-=-=-=-=-