Re: [edk2-devel] [RFC PATCH 00/11] Permit DXE drivers to execute in place

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

On Thu, 1 Jun 2023 at 16:53, Oliver Smith-Denny
<osde@linux.microsoft.com> wrote:
>
> Thanks for sending out this RFC, great to see more work on the memory
> protections front. A few questions and thoughts:
>
> This seems a good effort (in conjunction with your last RFC) to close
> the protection gap between DxeCore launch and CpuDxe launch for marking
> non-code regions NX. Do you see other protections (guard pages for
> example) fitting into this method? I believe for any dynamic protections
> during this timeframe we would need the ability to manipulate the page
> tables directly from DxeCore.
>

The use case of guard pages did not really occur to me, to be honest,
and this is obviously something that doesn't work either before the
CPU arch protocol is dispatched

I still think it would be preferable to add the ability to manage
memory mapping permissions to the DXE core itself, and separate it
from the CPU arch protocol.

Note that clumping everything together does not really help in this
respect either: if the memory permission manipulation logically
remains a part of the CPU arch protocol, which cannot be installed
until its dependencies are satisfied, we are still in a situation
where dispatching those dependencies may result in page allocations
being created before we can unmap the guard pages.

> Similarly, in order to lessen the complexity of the DXE driver usage of
> memory resources and avoiding sync issues (e.g. a driver allocates pages
> that are mapped NX by default, then it sets a cacheability attribute
> and accidentally clears NX), I think further work would be valuable to
> reduce that complexity. I think your new PPI that allows setting and
> preserving bits independently of what is passed in is a very good step
> towards reducing this complexity.
>

Hopefully, we'll be able to do something at the library/driver level
here (AllocatePages in the DMA or PCI layer).

Another thing we might entertain (which maps really well onto the WXN
thing we have on ARM) is to add a GCD memory region capability that
makes memory XP unless it is RO. But I haven't really experimented
with that yet - I'll keep you posted on that.

> This patchset would move all properly aligned DXE drivers to be XIP,
> correct?

Yes.

> Because we are XIP in DRAM, this should not have any
> performance implications (other than a benefit from reducing the extra
> copies in your first few patches), aside from potential space
> differences, which as you note compression will likely do away with,
> right?
>

Exactly.