Re: [edk2-rfc] [edk2-devel] RFC: design review for TDVF in OVMF

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

On 06/22/2021 9:35 PM, Laszlo wrote:
> Hi,
> 
> On 06/11/21 08:37, Xu, Min M wrote:
> > In today's TianoCore Design Meeting we reviewed the Overview Section
> (from slide 1 to 20). Thanks much for the valuable feedbacks and comments.
> The meeting minutes will be sent out soon.
> >
> > To address the concerns of the *one binary* solution in previous
> > discussion, we propose 2 Configurations for TDVF to upstream. (slide 6
> > - 8)
> >
> >
> >
> > Config-A:
> >
> >   *   Merge the *basic* TDVF feature to existing OvmfX64Pkg.dsc. (Align
> with existing SEV)
> >   *   Threat model: VMM is NOT out of TCB. (We don't make things worse.)
> >   *   The OvmfX64Pkg.dsc includes SEV/TDX/normal OVMF basic boot
> capability. The final binary can run on SEV/TDX/normal OVMF
> >   *   No changes to existing OvmfPkgX64 image layout.
> >   *   No need to add additional security features if they do not exist today
> >   *   No need to remove features if they exist today.
> >   *   RTMR is not supported
> >   *   PEI phase is NOT skipped in either Td or Non-Td
> 
> (so this is "Config-A / Option B", per slide 9 in the v0.9 slide deck)
>
Yes,  in Config-A we chose to follow the standard EDK2 flow (SEC -> PEI -> DXE -> BDS)
So that the changes in Config-A is not too intrusive.
>
> 
> >
> >
> >
> > Config-B:
> >
> >   *   Add a standalone IntelTdx.dsc to a TDX specific directory for a *full*
> feature TDVF. (Align with existing SEV)
> >   *   Threat model: VMM is out of TCB. (We need necessary change to
> prevent attack from VMM)
> >   *   IntelTdx.dsc includes TDX/normal OVMF basic boot capability. The final
> binary can run on TDX/normal OVMF
> >   *   It might eventually merge with AmdSev.dsc, but NOT at this point of
> time. And we don't know when it will happen. We need sync with AMD in
> the community, after both of us think the solutions are mature to merge.
> >   *   Need to add necessary security feature as mandatory requirement,
> such as RTMR based Trusted Boot support
> >   *   Need to remove unnecessary attack surfaces, such as network stack.
> 
> After reading the above, and checking slides 6 through 10 of the v0.9 slide
> deck:
> 
> - I prefer Config-B (IntelTdx.dsc).
> 
> This is in accordance with what I wrote earlier about "OvmfPkgX64.dsc"
> maintainability and regressions.
> 
> Additionally (given that a full-featured TDVF is the ultimate goal), I see the
> advance from "Config-A / option B" to "Config-B" a lot less
> *incremental* than the step from "OvmfPkgX64.dsc" to "AmdSev.dsc" was.
> 
> Put differently, I think that any TDX work targeted at "OvmfPkgX64.dsc"
> is going to prove less useful for the final "IntelTdx.dsc" than how reusable
> SEV work from "OvmfPkgX64.dsc" did for "AmdSev.dsc".
>
> Put yet differently, I'm concerned that a part of the TDX work for
> "OvmfPkgX64.dsc" might be a waste, with an eye towards the ultimate TDVF
> feature set ("IntelTdx.dsc").
> 
Actually Config-A and Config-B share some common (or basic) TDX features,
for example, the ResetVector, Memory Accept in SEC phase, IoMMU/DMA in
DXE phase, and the base IoLib, etc.
Config-A supports the basic Tdx features (except the security features).
Config-B supports the full set of Tdx features.
>
> 
> - I could (very cautiously) live with "Config-A / option B" as the initial
> approach. However, we'de have to be ready to make the full split (the
> switch-over to "IntelTdx.dsc") at *any point* during development, in case
> something turns out to be too intrusive. (And yes, "too intrusive" is
> subjective.)
>
Yes, we will always keep in mind the maintainability and regressions about
"OvmfPkgX64.dsc". So as the initial approach, only the basic Tdx features will
be included in Config-A.
>
> By this I mean that any particular patch towards "Config-A / option B"
> could cause me to ask, "please create IntelTdx.dsc now". Note that the later
> we make the switch the more painful it could be (= the more invested in
> "OvmfPkgX64.dsc" we could be, at that point).
>
Yes we will submit the patch for Config-B when any particular patch towards
"Config-A", so that we will not have a big surprise in the future.
>

Thanks!
Min