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/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
