[edk2-devel] [PATCH V3 15/29] OvmfPkg: Update SecEntry.nasm to support Tdx

[Gerd Hoffmann]

  Hi,

> Please refer to PI specification 1.7A (https://uefi.org/sites/default/files/resources/PI_Spec_1_7_A_final_May1.pdf)
> Section 2.1 - Introduction.

> "Philosophically, the PEI phase is intended to be the thinnest amount
> of code to achieve the ends listed above. As such, any more
> sophisticated algorithms or processing should be deferred to the DXE
> phase of execution."

Well, that might have been the original intention.  Reality is that a
bunch of security-related stuff ended up in PEI too.  Support for TPM,
SMM, suspend.  And I think the motivation for that is exactly what James
described:  Given that most communication with external entities happens
in the DXE phase it is much harder to trick PEI code because there are
simply less attack vectors available.

> I am not convinced that "exposure (external interface)" is a good
> reason to decide where the module should be.  Thinking of this, if you
> prefer to put a module to the PEI because PEI has *less* exposure,
> then PEI will have *more* exposure after that.  If you move half of
> DXE features to PEI, then PEI has same exposure as DXE. What benefit
> we can get?

Why is TPM and SMM and suspend support in PEI not DXE today?

> > Moving code to SEC has its problems too.  SEC is a much more restricted
> > environment.  A direct consequence is that you have re-invented
> > multiprocessor job scheduling (using tdx mailbox) instead of using
> > standard mp service for parallel accept.  I do not account that as
> > "reducing complexity".
> 
> [Jiewen] OK. Let me explain multiprocessor related topic.
> 
> I don't think we intent to "reduce" complexity in this area. I would
> say, it is same with or without PEI.
> 
> TDX (also SEV) has special requirement to *accept* memory, before use
> it. The accepting is time consuming process.  So the motivation is to
> use multiprocessor to accelerate the process.
> 
> We have at least three architecture places to accept the memory - SEC,
> PEI and DXE.

Well, I want focus on how all this will look like long-term, i.e. once
we have lazy accept implemented.  I don't think it makes sense to put
much effort into optimizing a workflow which will only be temporary
anyway.

The lazy accept concept pretty much implies that the vast majority of
memory will either be accepted in the DXE phase, or will not be accepted
by the firmware at all and the linux kernel will handle that instead.

I expect in the future SEC and/or PEI will accept barely enough memory
that the firmware is able to enter the DXE phase and initialize core
memory management.  Then lazy accept takes over.

> A) Accept in SEC
> We need write multiprocessor code in SEC. This is already mandatory,
> even without accepting memory.  The TDX architecture already changes
> the reset vector flow - ALL processors jumps to the reset vector at
> same time.  Having multiprocessor code in SEC is unavoidable. We have
> to do it, to rendez-vous APs and initialize mailbox.

Sure.

> The code is written because of TDX architecture change, not because
> memory accepting. So I won't treat it as a burden to add additional
> feature to memory accept in SEC.

That is the point where you start re-inventing the wheel though.
You add logic to distribute memory acceptance jobs to the APs.
I'd suggest to add full MP service support to TDX (probably also using
the mailbox), then use MP service to distribute memory acceptance jobs
to the APs. I think you will need that anyway for lazy accept, to do
parallel accept in DXE phase.

> B) Accept in PEI
> PEI has MP_PPI, that is TRUE. But the problem is: MP_PPI starts *later*.
> MP_PPI starts *after* the memory discovery (https://github.com/tianocore/edk2/blob/master/UefiCpuPkg/CpuMpPei/CpuMpPei.c#L706), which mean the process will be:
> Step 1: TdxPeim accepts PEI required memory without MP_PPI
> Step 2: PlatformPei installs PEI required memory.
> Step 3: MP_PPI starts.
> Step 4: TdxPeim accepts additional memory with MP_PPI

Yes.  Or just don't initialize MP in PEI and do that in DXE only.
Lazy accept will need that anyway.

> Now, you can see the benefit to accept PEI memory is not there.
> NOTE: PEI memory is ~64M if GPAW is 48, it is ~98M if GPAW is 52, which is a big number.

What is all this memory needed for?
Why do you need 32M additional memory for 5-level paging?
Is that page table memory?  If so, how does lazy accept change the
picture?

> As such, we conclude that doing memory accept in SEC is the best
> choice for TDX architecture.

Not convinced this is still the case with lazy accept on the horizon.

> For config-B, Min is working on it and doing clean up.
> You are welcome to provide feedback after we send out patch for config-B.

Will do for sure.

take care,
  Gerd



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#84203): https://edk2.groups.io/g/devel/message/84203
Mute This Topic: https://groups.io/mt/86739864/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [edk2-devel-archive at redhat.com]
-=-=-=-=-=-=-=-=-=-=-=-