On Thu, 1 Jun 2023 at 16:53, Oliver Smith-Denny <o...@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. -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#105598): https://edk2.groups.io/g/devel/message/105598 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] -=-=-=-=-=-=-=-=-=-=-=-
