Current code, for example guarding code, asserts implications between memory protection attributes. For example, pages that are supposed to be unmapped only get marked as EFI_MEMORY_RP[1][2], as the code expects this to imply WP and NX. While it seems intuitive that excluded read permissions imply excluded execute permissions, e.g. ARM does support this[3]. Write-only pages are rare in practice, but yet again this does exist.

On the caller side, the most granular values should be passed in. For unmapped pages for example, this should be "EFI_MEMORY_RP | EFI_MEMORY_RO | EFI_MEMORY_XP". "EFI_MEMORY_RO" in this case should be defined as "write-protected" rather than "read-only" (unfortunately the WP name is occupied by caching attributes). The architectural implementation should then deal with its own limitations to satisfy the request the best way it can, or return an error, whichever makes more sense for the attribute combination.

[1] https://github.com/tianocore/edk2/blob/2072c22a0d63c780b0cc6377f6d4ffb116ad6144/MdeModulePkg/Core/Dxe/Mem/HeapGuard.c#L521

[2] https://github.com/tianocore/edk2/blob/2072c22a0d63c780b0cc6377f6d4ffb116ad6144/MdeModulePkg/Core/Dxe/Mem/HeapGuard.c#L1311-L1316

[3] https://developer.arm.com/documentation/dui0471/m/embedded-software-development/execute-only-memory