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

["Yao, Jiewen" <jiewen.yao@intel.com>]

> -----Original Message-----
> From: kraxel@redhat.com <kraxel@redhat.com>
> Sent: Wednesday, December 1, 2021 9:55 PM
> To: Yao, Jiewen <jiewen.yao@intel.com>
> Cc: devel@edk2.groups.io; jejb@linux.ibm.com; Xu, Min M
> <min.m.xu@intel.com>; Ard Biesheuvel <ardb+tianocore@kernel.org>; Justen,
> Jordan L <jordan.l.justen@intel.com>; Brijesh Singh <brijesh.singh@amd.com>;
> Erdem Aktas <erdemaktas@google.com>; Tom Lendacky
> <thomas.lendacky@amd.com>
> Subject: Re: [edk2-devel] [PATCH V3 15/29] OvmfPkg: Update SecEntry.nasm to
> support Tdx
> 
>   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.

[Jiewen] Again, I feel lost.

Would you please clarify what is your purpose for this discussion?

Yes, Security related stuff in PEI, that is not a problem. For example, we moved flash lock from DXE to PEI. (I already describe that in my previous email.)
The key is *privilege*. If you don't need PEI privilege, you don't need move to PEI.

1) For "TPM" feature. In history, the Root-of-trust for measurement (RTM) belongs to Recovery TR. That is why it is in PEI naturally.
2) "SMM" support is in DXE today. What do you mean SMM support in PEI ?
3) "Suspend" is S3 *feature*, it is clearly documented in PI spec. In S3, DXE does not run. You have to put Suspend code in PEI.

Yes, you give some examples.
But I don't see how the examples support your statement on "exposure".
IMHO, they are totally unrelated.



> > 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?
[Jiewen] See above.

> 
> > > 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.

[Jiewen] This is the long-term solution.
Lazy accept and MP accept are two required feature.

"Lazy accept" just mean you can do things later, but you still need do it.
"MP accept" means you can do things much quicker.

I don't think we can remove MP accept just because we have lazy accept.


> 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.

[Jiewen] the "barely enough memory" is 64M and it takes long time to accept if you don't use MP.
That is how SEC/PEI/DXE designed today.



> > 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.

[Jiewen] I think I have stated it clearly that this is due to TDX architecture, we have to rendezvous all APs in SEC.
So the MP code SEC is unavoidable. We have to reinvent the wheel in some way.


> 
> > 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/CpuM
> pPei.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?

[Jiewen] These are initial memory for PEI Core and DXE Core to initialize the content.
If you don't have initial memory, the core will fail.



> 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.

[Jiewen] I think MP accept is irrelevant to lazy accept, as I explained before.

Having "lazy accept" != you can drop "MP accept" in SEC, because SEC is to "accept initial memory" before you can do lazy.


> 
> > 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