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. > 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). > 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. 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. > > 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? take care, Gerd -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#84409): https://edk2.groups.io/g/devel/message/84409 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] -=-=-=-=-=-=-=-=-=-=-=-
