Re: [edk2-devel] [PATCH V7 1/1] OvmfPkg: Enable TDX in ResetVector

["Min Xu" <min.m.xu@intel.com>]

On September 24, 2021 1:28 PM, Gerd Hoffmann wrote:
>   Hi,
> 
> > > SEV hardware does not have a concept of the metadata. To boot SEV
> > > guest we need to pass some information to VMM and in past those
> > > information were passed through SNP_BOOT_BLOCK (GUIDed structure)
> > > but Gerd recommended that it will be good idea if both SEV and TDX
> > > uses a common metadata approach to pass these information. I
> > > personally think it was a good suggestion. So, in SNP series I went
> > > ahead and created a generic metadata structure and  hope that TDX
> > > will build on it. The user of the metadata structure is VMM (qemu,
> > > etc); while launching the guest the VMM knows whether its creating the
> SEV or TDX guest and will process the entries accordingly.
> > >
> > > As per the number of fields in the metadata is concerns, I felt 3
> > > fields (start, size and type) should be good enough for all the
> > > cases. There was a question from Gerd to Min asking why do you need
> > > the dataoffset/rawdatasize etc and I don't remember seeing the answer
> for it.
> >
> > The discussion is in this link.
> > https://edk2.groups.io/g/devel/message/80289
> 
> The question why TDX_BFV_RAW_DATA_OFFSET and
> TDX_BFV_RAW_DATA_SIZE are needed and why TDX_BFV_MEMORY_BASE +
> TDX_BFV_MEMORY_SIZE can't be used is still open.
Here is a BFV metadata.
    37                                                           <1> _Bfv:
    38 00000140 00400800                     <1>   DD TDX_BFV_RAW_DATA_OFFSET
    39 00000144 00C03700                     <1>   DD TDX_BFV_RAW_DATA_SIZE
    40 00000148 0040C8FF00000000    <1>   DQ TDX_BFV_MEMORY_BASE
    41 00000150 00C0370000000000    <1>   DQ TDX_BFV_MEMORY_SIZE
    42 00000158 00000000                      <1>   DD TDX_METADATA_SECTION_TYPE_BFV
    43 0000015C 01000000                      <1>   DD TDX_METADATA_ATTRIBUTES_EXTENDMR

TDX_BFV_RAW_DATA_OFFSET/TDX_BFV_RAW_DATA_SIZE indicates the offset/size of BFV in Ovmf.fd.
TDX_BFV_MEMORY_BASE/ TDX_BFV_MEMORY_SIZE is the physical memory address which is to be mapped.
TDX-QEMU use these information to 1) do the measurement of the BFV 2) map the BFV to the physical memory

> 
> While being at it: The question why "config-b" with a completely different
> initialization code path is needed is still open too.  The tdvf design guide is
> not helpful here.  Although explains what is different in "config-a" vs. "config-
> b" it does not explain the background, i.e. why some features are supported
> by "config-b" only.
The solution of Config-A and Config-B is to address the concerns of One-Binary requirement.
See Erdem Aktas's comments in this link https://edk2.groups.io/g/devel/message/76339
Quote: "What we are asking with "one binary" is: Simply enabling OVMF + a guest OS to boot in a TDX domain without breaking any existing functionality.  Intel should put everything else (specifically related to remote attestation) in a separate platform configuration."

*Config-A* enables a minimum functionality in OvmfPkgX64.dsc without breaking existing functionality.
*Config-B* is a separate platform  configuration file can be used to provide all the security guarantees that TDX provides.

> 
> And I guess these two questions are related.  With "config-a" there is a fixed
> offset between TDX_BFV_RAW_DATA_OFFSET + TDX_BFV_MEMORY_BASE,
> so if you know one of them you can easily calculate the other.  With "config-
> b" this is possibly not the case.
> 
> So, can you please shed some light on this?
As I explained above how BFV metadata is used by TDX-QEMU, there is no different in Config-A and Config-B.

Below are some links discussing the Config-A and Config-B. Hope it is helpful.

Config-A and Config-B:
https://edk2.groups.io/g/devel/message/76367
Erdem Aktas's comments:
https://edk2.groups.io/g/devel/message/76339
Laszlo's comments
https://edk2.groups.io/g/devel/message/76836
https://edk2.groups.io/g/devel/message/76837

Thanks!
Min