Re: [edk2-devel] [Patch V3 0/8] Create page table by CpuPageTableLib in DxeIpl

["Ni, Ray" <ray.ni@intel.com>]

I can think of 3 options:
1. Create MdeModulePkg/HandOffToDxeCoreLib lib class. UefiCpuPkg implements the two instances supporting 32/64bit PEI.
2. Create MdeModulePkg/Ppi/EdkiiMemoryAttribute.h. UefiCpuPkg/CpuMpPei implements the X86 version of MemoryAttribute PPI.
     (As what Ard did in ArmCpuDxe driver.)
     The MemoryAttribute PPI only supports to modify the memory attribute in the active page table. It cannot modify the "future" page table
     which is the case DxeIpl/Ia32 creates long-mode page table.
      So, this option cannot help on DxeIpl/Ia32. I will have to keep DxeIpl/Ia32 code unchanged and only cleanup the DxeIpl/X64 by calling the new PPI.
3. A slight different version of option #2: create MdeModulePkg/MemoryAttributeLib lib class instead of PPI. I would prefer #2.


Option #1 helps to create single DxeIpl PEIM but doesn't help to abstract memory attributes changing in whole PEI phase.
With Option #2, multiple DxeIpl PEIMs still exist for different archs.

I am fine with either option #1 or #2 because either can avoid MdeModulePkg depending on UefiCpuPkg.

Thoughts?

> > >
> > > The problem I have had to work around in my strict permissions series
> > > (which includes the linked patch) is that there is a window from the
> > > moment DXE core is dispatched until the moment the CPU arch protocol
> > > DXE driver is dispatched where we don't have an architectural means to
> > > manipulate memory permissions.
> > >
> > > So what we'd need here is a library version of the following method
> > >
> > > typedef
> > > EFI_STATUS
> > > (EFIAPI *EFI_CPU_SET_MEMORY_ATTRIBUTES)(
> > >   IN EFI_CPU_ARCH_PROTOCOL              *This,
> > >   IN  EFI_PHYSICAL_ADDRESS              BaseAddress,
> > >   IN  UINT64                            Length,
> > >   IN  UINT64                            Attributes
> > >   );
> >
> > What's your idea here?
> > Besides HandOffToDxeCore(), you require a 2nd lib API as above for
> > early DXE phase before CPU AP is available?
> >
> > Why do we want to combine two APIs into one lib class?
> > If combined, what lib class name do you think is proper to describe the lib
> purpose?
> >
> > It seems to me lacking of CPU AP in early DXE phase is acknowledged by PI
> spec.
> > Having the 2nd API for DXE early phase is like a workaround to fix PI spec
> gap, do you think so?
> >
> 
> Perhaps. Maybe the problem here is that there setting memory
> permissions is not part of the PEI CPU arch protocol. It would make
> sense for shadowed PEIMs as well as the DXE core to be mapped with
> strict permissions at dispatch time (if the section alignment permits
> it). For XIP PEIMs, nothing would change, and if PEI executes in place
> from DRAM, the whole FV can be mapped read-only.
> 
> Or perhaps this should be a separate PPI altogether, and we could
> define it as one that is callable from DXE core if the CPU arch
> protocol has not been dispatched yet.
> 
> I don't really care whether or not we add this to the PI spec tbh
> 
> > >
> > > *However*, I am aware that the X86 DXE IPL code deviates from this, as
> > > it needs to build long mode compatible page tables before switching
> > > from IA32 to X64, right?
> >
> > DXEIPL creates long mode page table with following characteristics:
> > * 1:1 mapping to cover the entire memory space
> > * Set the bottom 4K of BSP stack as not-present - prevent stack overflow
> > * Set the entire BSP stack as NX - prevent buffer overflow attack
> > * Set the [0-4k] region as not-present - null protection
> >
> > But it doesn't set DxeCore code region as RO, or data region as NX.
> >
> > I describe the X86 DXEIPL page table behavior as above. Because I hope
> > you could explain a bit more on your thoughts. I don't quite understand
> > your above wordings.
> >
> 
> I guess the long mode switch is sufficiently special that it will be
> very hard to define a sane API that covers all of this. OTOH, it seems
> like a missed opportunity to rely on DXE IPL to create all these
> restricted mappings, and invent something completely new just to remap
> the DXE core text and data sections RO / XP. And note that, for arm64,
> this should occur before the code is actually called, since the
> restricted mode we would like to enable for EDK2 does not permit
> memory that is both writable and executable at all.
> 
> 
> 
>