[edk2-devel] [PATCH V2 4/4] OvmfPkg/ResetVector: Update ResetVector to support Tdx

[Min Xu]

On July 23, 2021 1:08 AM, Tom Lendacky wrote:
> On 7/22/21 12:52 AM, Min Xu wrote:
> > RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3429
> >
> > diff --git a/OvmfPkg/ResetVector/Ia32/Flat32ToFlat64.asm
> > b/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?
>
>
> >      mov     eax, cr4
> >      bts     eax, 5                      ; enable PAE
> >      mov     cr4, eax
> > @@ -65,10 +68,54 @@ EnablePaging:
> >      bts     eax, 31                     ; set PG
> >      mov     cr0, eax                    ; enable paging
> >
> > +    jmp     _jumpTo64Bit
> > +
> > +;
> > +; Tdx Transition from 32Flat to 64Flat ;
> > +TdxTransition32FlatTo64Flat:
> > +
> > +    mov     eax, cr4
> > +    bts     eax, 5                      ; enable PAE
> > +
> > +    ;
> > +    ; byte[TDX_WORK_AREA_PAGELEVEL5] holds the indicator whether
> 52bit is supported.
> > +    ; if it is the case, need to set LA57 and use 5-level paging
> > +    ;
> > +    cmp     byte[TDX_WORK_AREA_PAGELEVEL5], 0
> > +    jz      .set_cr4
> > +    bts     eax, 12
> > +.set_cr4:
> > +    mov     cr4, eax
> > +    mov     ebx, cr3
> > +
> > +    ;
> > +    ; if la57 is not set, we are ok
> > +    ; if using 5-level paging, adjust top-level page directory
> > +    ;
> > +    bt      eax, 12
> > +    jnc     .set_cr3
> > +    mov     ebx, TDX_PT_ADDR (0)
> > +.set_cr3:
> > +    mov     cr3, ebx
> > +
> > +    mov     eax, cr0
> > +    bts     eax, 31                     ; set PG
> > +    mov     cr0, eax                    ; enable paging
> 
> If you clear ebx here...
>
> > +
> > +_jumpTo64Bit:
> >      jmp     LINEAR_CODE64_SEL:ADDR_OF(jumpTo64BitAndLandHere)
> > +
> >  BITS    64
> >  jumpTo64BitAndLandHere:
> >
> > +    ;
> > +    ; For Td guest we are done and jump to the end
> > +    ;
> > +    mov     eax, TDX_WORK_AREA
> > +    cmp     dword [eax], 0x47584454 ; 'TDXG'
> > +    jz      GoodCompare
> > +
> 
> ... you can remove these instructions. You'll jump to InsnCompare and that
> check should succeed, right?
>
Ah, I see. Thanks for reminder. I will update it in next version.
>
> Thanks,
> Tom
> 
> >      ;
> >      ; Check if the second step of the SEV-ES mitigation is to be performed.
> >      ;


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