public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Gerd Hoffmann" <kraxel@redhat.com>
To: "Xu, Min M" <min.m.xu@intel.com>
Cc: "devel@edk2.groups.io" <devel@edk2.groups.io>,
	"Kinney, Michael D" <michael.d.kinney@intel.com>,
	Brijesh Singh <brijesh.singh@amd.com>,
	"Aktas, Erdem" <erdemaktas@google.com>,
	James Bottomley <jejb@linux.ibm.com>,
	"Yao, Jiewen" <jiewen.yao@intel.com>,
	Tom Lendacky <thomas.lendacky@amd.com>
Subject: Re: [edk2-devel] [PATCH 08/10] OvmfPkg: Update Sec to support Tdvf Config-B
Date: Tue, 11 Jan 2022 10:23:04 +0100	[thread overview]
Message-ID: <20220111092304.2n72req6ocdkqfub@sirius.home.kraxel.org> (raw)
In-Reply-To: <PH0PR11MB50648CA04308F0E7F135CB3DC5519@PH0PR11MB5064.namprd11.prod.outlook.com>

  Hi,

> > Well, if you want avoid the refactoring because of the risk there is still the
> > option to have tdx config-b use the normal PEI boot flow.
> > Then revisit refactoring and adding support for PEI-less boot later.
> > 
> I think it still makes sense (Adding a basic PlatformInitLib which
> brings up tdx guest and legacy guest in Pei-less boot, but not touch
> PlatformPei).

> 1. The goal of TDVF-Config-B is to bring up tdx guest and legacy guest
> without PEI. So that attack surface can be reduced.

Hmm?  Isn't the main goal of config-b to support the advanced tdx
features (attestation etc)?

I don't see that PEI-less boot is required for that.  Sure, when
stripping down the build and removing all the features which require
PEIMs there isn't much left to do for the PEI phase.  So it makes sense
to look into dropping PEI altogether.  But it's more a "nice to have"
than a hard requirement, no?

> 2. There are common functions when bring up tdx guest and legacy guest
> in Config-B. So PlatformInitLib is necessary.

Sure.

> 3. As I explained there are many if-else checks in PlatformPei and the
> logics are rather complicated (because PlatformPei serves
> S3/SMM/SEV/TDX/Legacy/Microvm/CloudHypervisor, etc). To be honest I
> have not so much confidence to abstract PlatformPei's common function
> to PlatformInitLib.

What is the problem with moving code?  After some preparing steps (add
platform info hob, move global variables to the hob) it should be
possible to move the code needed by config-b (memory detection via
fw_cfg or tdx hob, pci init, ...) from PlatformPei to PlatformInitLib
and (also) use it in the SEC phase.  Likewise for code which runs in DXE
in PEI-less mode (setting PCDs).

The code not needed by config-b (smm, s3, ...) can stay in PlatformPei.

> 4. But a basic version of PlatformInitLib is a good start.

Yes.  Having initially only the functions needed by config-b in
PlatformInitLib is perfectly fine, but this should be a code *move*
not a copy.

> During the development and community review, we can understand better
> what functions should be wrapped into PlatformInitLib. After that
> PlatformInitLib can be evolved for OvmfPkg/PlatformPei,
> Bhyve/PlatformPei, XenPlatformPei.

Yes, most likely there are a number of opportunities to reduce code
duplication in the three PlatformPei variants we have by moving code
to the (shared) PlatformInitLib.

That can be looked at later.

take care,
  Gerd


  reply	other threads:[~2022-01-11  9:23 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-14 13:41 [PATCH 00/10] Introduce TDVF Config-B (basic) in OvmfPkg Min Xu
2021-12-14 13:41 ` [PATCH 01/10] OvmfPkg: Introduce IntelTdxX64 for TDVF Config-B Min Xu
2021-12-15  9:32   ` Gerd Hoffmann
2021-12-14 13:41 ` [PATCH 02/10] EmbeddedPkg/PrePiLib: Update PrePiLib Min Xu
2021-12-14 14:00   ` [edk2-devel] " Ard Biesheuvel
2021-12-16  4:48     ` Min Xu
2021-12-14 13:41 ` [PATCH 03/10] EmbeddedPkg/MemoryAllocationLib: Add null stub for AllocateCopyPool Min Xu
2021-12-14 13:59   ` [edk2-devel] " Ard Biesheuvel
2021-12-16  3:08     ` Min Xu
2021-12-14 13:41 ` [PATCH 04/10] OvmfPkg: Add PrePiHobListPointerLibTdx Min Xu
2021-12-14 13:41 ` [PATCH 05/10] OvmfPkg: Add SecPlatformLibQemuTdx Min Xu
2021-12-15  9:48   ` Gerd Hoffmann
2022-01-07  6:29     ` Min Xu
2021-12-14 13:41 ` [PATCH 06/10] OvmfPkg: Add TdxStartupLib Min Xu
2021-12-15 10:09   ` Gerd Hoffmann
2021-12-16 11:56     ` Min Xu
2022-01-12  1:55       ` Min Xu
2021-12-14 13:41 ` [PATCH 07/10] OvmfPkg: Update TdxDxe to set TDX PCDs Min Xu
2021-12-14 13:41 ` [PATCH 08/10] OvmfPkg: Update Sec to support Tdvf Config-B Min Xu
2021-12-15 10:27   ` Gerd Hoffmann
2021-12-16 12:21     ` [edk2-devel] " Min Xu
2021-12-16 14:25       ` Gerd Hoffmann
2021-12-19  2:49         ` Min Xu
2021-12-20 12:11           ` Gerd Hoffmann
2021-12-24  3:02             ` Min Xu
2022-01-03  8:02               ` Gerd Hoffmann
2022-01-07  6:13                 ` Min Xu
2022-01-10  7:55                   ` Gerd Hoffmann
2022-01-11  2:24                     ` Min Xu
2022-01-11  9:23                       ` Gerd Hoffmann [this message]
2022-01-14  2:17                         ` Min Xu
2022-01-14  8:32                           ` Gerd Hoffmann
2022-01-16  0:55                             ` Min Xu
2021-12-14 13:41 ` [PATCH 09/10] OvmfPkg: Update DxeAcpiTimerLib to read HostBridgeDevId in PlatformInfoHob Min Xu
2021-12-14 13:41 ` [PATCH 10/10] OvmfPkg: Add Tdx libs to prevent building broken Min Xu
2021-12-15 10:41 ` [PATCH 00/10] Introduce TDVF Config-B (basic) in OvmfPkg Gerd Hoffmann
2021-12-16 12:36   ` Min Xu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220111092304.2n72req6ocdkqfub@sirius.home.kraxel.org \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox