Re: [edk2-devel] [PATCH 08/10] OvmfPkg: Update Sec to support Tdvf Config-B

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

On December 16, 2021 10:25 PM, Gerd Hoffmann wrote:
> > > Oh, wow.  So you compile in PEI, then decide at runtime whenever you
> > > use it or not?
> > Yes.
> > In OvmfPkgX64.dsc above code will not be built into the image. So it follows
> the SEC->PEI->DXE flow.
> > In IntelTdxX64.dsc, it if is Tdx guest, it jumps from SEC to DXE (see TdxStartup
> ()). Otherwise, it follows the SEC->PEI->DXE flow (Legacy guest, SEV guest, etc).
> 
> > > No.  Please don't.  That's just silly.  If you don't want use PEI,
> > > ok, fine, but please go the way then, remove PEI from the build and
> > > take the PEI-less code path in all cases.
> 
> > In the first version TDVF, we do remove the PEI from the image. The
> > image only contains the SEC and DXE, and only the components TDVF
> > needs. It's a slim image.  Then the *ONE BINARY* requirement is
> > proposed. It requires to bring up Legacy guest and Tdx guest with the
> > same image. So PEI must be included in the build,
> 
> Why?  Booting non-tdx guests without PEI shouldn't be fundamentally
> different from a TDX guest.  Memory detection needs fw_cfg instead of the
> td_hob, and you have to skip some tdx setup steps, but that should be it.
> Code for all that exists in PlatformPei, it only needs to be moved to a place
> where SEC can use it too.
> 
> Yes, you can't include a number of features which depend on PEI into the build
> then.  But config-b wants be a stripped down build anyway, right?
> 
> One major advantage of having a single binary is that most aspects of the SEC-
> >DXE boot workflow can also be tested without TDX.  Easier for developers.
> Easier for CI coverage.  Especially now where we talk about pre-production
> hardware support.
> 
> When builing a frankenstein image which uses SEC->DXE with TDX and
> SEC->PEI->DXE without TDX you loose that advantage, because that is
> effectively a two-in-one binary.
> 
> > and it probes Tdx
> > guest in run-time so that it decides to go to the legacy flow
> > (SEC->PEI->DXE) or Tdx flow (SEC->DXE).
> 
> Ok, so the state with wave-2 merged will be:
> 
>   * We have the ovmf build, which supports native/sev/tdx guests,
>     with basic tdx support (aka config-a).
> 
>   * We have the amdsev variant (supports native/sev/not-sure-about-tdx),
>     which is largely identical to the normal build, only unwanted
>     drivers removed (no network etc), grub boot loader added and its own
>     PlatformBootManagerLib to have a more strict boot policy (all dxe
>     phase changes).
> 
> So, where to go from here?
> 
> 
> I still think the best way forward would be to model the inteltdx build (aka
> config-b) similar to the amdsev variant.  Just disable the stuff you don't need,
> add support for the advanced tdx features (measurement etc), but otherwise
> continue to use the same SEC->PEI->DXE boot workflow.
> 
> Advantages:
>   * It should be relatively easy to unify amdsev + inteltdx into one
>     binary.
>   * No quirks needed due to SEC/PEI differences.  SEC can't set PCDs,
>     leading to patches like #9 of this series (and there was another
>     similar one ...).
> 
> 
> The other route (as preferred by Jiewen) would be to not use PEI in inteltdx.
> Requires some reorganization of the qemu platform initialization code
> (probably move to lib) so we can run the same code (without using cut+paste
> programming) in both sec and pei phase.
> Clearly not my preference, but should work too.
> 
> A better solution for the PCD issue (and possibly other simliar issues poping up
> later) would be good.  Can't we handle that early in PlatformDxe?  So we have
> one single place for those quirks, and the dxe drivers don't need to know
> about the SEC->DXE and SEC->PEI->DXE differences?
> 
Thank Gerd for the review comments.
Yes, TDVF Config-B is a strip down and it is to be a more secure solution (because RTMR based measurement/measure boot is enabled, un-used drivers are excluded to reduce attack surface, sanity check/measure all external inputs, etc).

We would like to split TDVF Config-B into below stages.
1. Basic Config-B (wave-3)
1.1 A standalone IntelTdxX64.dsc/.fdf. Un-used drivers/libs are removed from the fdf, such as network components, SMM drivers, TPM drivers, etc.
1.2 PEI FV is excluded from the build. Only DxeFV is included.
1.3 Since PEI FV is excluded from the build, so Basic Config-B can only bring up Tdx guest. It *CAN NOT* bring up legacy guest.

2. Advanced Config-B (wave-4)
2.1 RTMR based measurement and measure boot are enabled
2.2 External input is checked and measured

3. Full feature Config-B (wave-5)
3.1 Add *basic* Ovmf feature without PEI, to achieve *ONE Binary* goal. (here basic means S3 is not supported without PEI)

@Gerd, What's your thought?

Thanks
Min