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

[Oliver Smith-Denny]

On 5/29/2023 3:16 AM, Ard Biesheuvel wrote:
> TL;DR - allow DXE drivers to execute in place from the decompressed FV
> 
> loaded into memory by DxeIpl so we can apply strict permissions before
> 
> dispatching DXE core.
> 
> 
> 
> Currently, executable images loaded from firmware volumes are copied at
> 
> least three times: once in the firmware volume driver, once in the DXE
> 
> core load image code, and finally when the PE sections are populated in
> 
> memory based on the section descriptions in the file.
> 
> 
> 
> At least two of these copies serve little purpose, given that most
> 
> drivers are typically dispatched from a memory-mapped firmware volume
> 
> that is loaded into DRAM by DxeIpl from a compressed image in the boot
> 
> FV, and so we can take a short-cut in the DXE image loader so that the
> 
> PE/COFF library that performs the load uses the image in the memory
> 
> mapped FV as its source directly. This is implemented by the first 6
> 
> patches (where the first 3 are just cleanups)
> 
> 
> 
> With this logic in place, we can go one step further, and actually
> 
> dispatch the image in place (similar to how XIP PEIMs are dispatched),
> 
> without over moving it out of the decompressed firmware volume. This
> 
> requires the image to be aligned sufficiently inside the FV, but this is
> 
> also the same logic that applies to XIP PEIMs, and this can be achieved
> 
> trivially by tweaking some FDF image generation rules. (Note that this
> 
> adds padding to the FV, but this generally compresses well, and we
> 
> ultimately uses less memory at runtime by not making a copy of the
> 
> image).
> 
> 
> 
> This requires the DXE IPL (which is the component that decompresses the
> 
> firmware volumes to memory) to iterate over the contents and relocate
> 
> these drivers in place. Given that DXE IPL is already in charge of
> 
> applying NX permissions to the stack and to other memory regions, we can
> 
> trivially extend it to apply restricted permissions to the XIP DXE
> 
> drivers after relocation.
> 
> 
> 
> This means we enter DXE core with those DXE drivers ready to be
> 
> dispatched, removing the need to perform manipulation of memory
> 
> attributes before the CPU arch protocol is dispatched, which is a bit of
> 
> a catch-22 otherwise.
> 
> 
> 
> With these changes in place, the platform no longer needs to map memory
> 
> writable and executable by default, and all DRAM can be mapped
> 
> non-executable right out of reset.
> 
> 

Hi Ard,

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.

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.

This patchset would move all properly aligned DXE drivers to be XIP,
correct? 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?

Thanks,
Oliver



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#105567): https://edk2.groups.io/g/devel/message/105567
Mute This Topic: https://groups.io/mt/99197132/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [edk2-devel-archive at redhat.com]
-=-=-=-=-=-=-=-=-=-=-=-