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

["Ard Biesheuvel" <ardb@kernel.org>]

On Tue, 25 Apr 2023 at 03:45, Ni, Ray <ray.ni@intel.com> wrote:
>
>
>
> > -----Original Message-----
> > From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Ard
> > Biesheuvel
> > Sent: Tuesday, April 25, 2023 2:07 AM
> > To: Kinney, Michael D <michael.d.kinney@intel.com>
> > Cc: devel@edk2.groups.io; Tan, Dun <dun.tan@intel.com>
> > Subject: Re: [edk2-devel] [Patch V3 0/8] Create page table by
> > CpuPageTableLib in DxeIpl
> >
> > On Mon, 24 Apr 2023 at 19:51, Kinney, Michael D
> > <michael.d.kinney@intel.com> wrote:
> > >
> > > Hi Ard,
> > >
> > > Thanks for the feedback.  Let's work on this approach.
> > >
> > > Are there similar needs for CPU related services in the DXE Core before
> > > the CPU AP is loaded?
> > >
> > > If we are going to define a new lib class to abstract DXE IPL requirements,
> > > it would be good to cover DXE Core requirements too.
> > >
> >
> > Yeah, excellent point.
> >
> > 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.