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/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
