[edk2-devel] [PATCH V7 1/1] OvmfPkg: Enable TDX in ResetVector
Min Xu
min.m.xu at intel.com
Fri Sep 24 06:55:29 UTC 2021
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
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#81067): https://edk2.groups.io/g/devel/message/81067
Mute This Topic: https://groups.io/mt/85761661/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [edk2-devel-archive at redhat.com]
-=-=-=-=-=-=-=-=-=-=-=-
More information about the edk2-devel-archive
mailing list