> -----Original Message-----
> From: kra...@redhat.com <kra...@redhat.com>
> Sent: Monday, December 6, 2021 10:58 PM
> To: Yao, Jiewen <jiewen....@intel.com>
> Cc: devel@edk2.groups.io; j...@linux.ibm.com; Xu, Min M
> <min.m...@intel.com>; Ard Biesheuvel <ardb+tianoc...@kernel.org>; Justen,
> Jordan L <jordan.l.jus...@intel.com>; Brijesh Singh <brijesh.si...@amd.com>;
> Erdem Aktas <erdemak...@google.com>; Tom Lendacky
> <thomas.lenda...@amd.com>
> Subject: Re: [edk2-devel] [PATCH V3 15/29] OvmfPkg: Update SecEntry.nasm to
> support Tdx
>
> Hi,
>
> > [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.)
>
> Well, you tried to make the point that PEI shouldn't do anything beyond
> memory initialization. Which might have been correct for the initial
> design, but meanwhile it is not true any more.
[Jiewen] No, I am not making this point.
My point is : It is legal to move a feature from PEI to DXE.
My understanding is that: you are making point - "It is problematic that moving
a feature from PEI to DXE". I take "feature" as "any generic feature".
I accept the statement that "It *may* be problematic that moving a *specific
(such as security)* feature from PEI to DXE".
But I disagree the general statement that moving any feature from PEI to DXE
will cause problem.
For PEI, my point is
1) According to PI spec, PEI is minimal so it is legal to move feature from PEI
to DXE.
2) We do see some examples that we move from DXE to PEI, but that is case by
case. It does not mean you cannot move feature from PEI to DXE.
>
> > The key is *privilege*. If you don't need PEI privilege, you don't need
> > move to
> PEI.
>
> > 2) "SMM" support is in DXE today. What do you mean SMM support in PEI ?
>
> ovmf has a pei module for smm support (see
> OvmfPkg/SmmAccess/SmmAccessPei.inf).
[Jiewen] The SmmAccessPei is for S3 resume. It is already documented to PI spec.
I don't see anything wrong here.
> > But I don't see how the examples support your statement on "exposure".
>
> Well, lets stick to the flash lock example. Moving it from DXE to PEI
> makes it less exposed. It'll run before DXE starts processing
> externally controlled input (efi vars, kbd input, disk reads, option
> roms, ...). So trying trick it into not actually locking the flash is
> much harder.
[Jiewen] I am tired on using word "exposure". You gave the definition that
"exposure == external interface".
And your statement is that we should move "feature" to the component with less
exposure. - I take "feature" as "any generic feature".
In my opinion, less exposure != high privilege. There might be some
relationship. A high privilege module may have less exposure usually. However,
the privilege is *cause*, less exposure is *consequence*. Not verse versa. We
made judgement based upon privilege, not the exposure.
I accept the statement that "We should move a *security* feature to component
with *high privilege*".
But I disagree the general statement that we should moving any feature to less
exposure.
I give a counter example - SMM. SMM has less external interface, but we cannot
move "any generic feature" to SMM.
>
> Or, to put it into another way, it reduces the attack surface for the
> code with higher privilege.
>
> (it's of course also need to make sure you can't unlock flash with a
> suspend-resume cycle).
>
> > > 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.
>
> I don't want remove it. But with lazy accept you have more options to
> implement it. No need to go for assembler code in SEC, you can use MP
> service with standard C code in PEI or DXE.
>
> > [Jiewen] the "barely enough memory" is 64M and it takes long time to
> > accept if you don't use MP.
>
> If I remember the numbers correctly (roughly 4 seconds for 2G on a
> single processor) that "long time" would be roughly 12 ms for 64M.
[Jiewen] OK, I talked with Min again. 12ms is not right data today.
We have bigger number, but I cannot share the data according to legal reason.
But I agree with your statement that, if the data is small enough, then we
don't need MP in sec.
I propose this way:
1) In first patch, we drop MP in SEC.
2) We can revisit if it is really needed later, when the TDX platform is about
to launch.
I believe we will have more precise data at that moment.
>
> > > 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.
>
> Well, adding TDX rendezvous support isn't re-inventing the wheel, you
> surely need that, no question.
>
> But then you go create your own job scheduler (also accept job
> implementation), all in assembler, instead of using standard edk2 MP
> services with more readable C code. *That* is where you re-invent the
> wheel.
>
> > > > 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.
>
> Where does the 50% increase for GPAW=52 comes from?
[Jiewen] Yes, this is about page table.
The reason is that UEFI spec requires you to map all memory. You have to create
page table for all.
>
> take care,
> Gerd
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#84438): https://edk2.groups.io/g/devel/message/84438
Mute This Topic: https://groups.io/mt/86739864/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
