diff options
author | Ard Biesheuvel <ardb@kernel.org> | 2023-06-02 17:17:36 +0200 |
---|---|---|
committer | mergify[bot] <37929162+mergify[bot]@users.noreply.github.com> | 2023-06-26 09:11:53 +0000 |
commit | 8f5ad634ad4b0593fce0e79f0f743af5f0cf4208 (patch) | |
tree | e58dc1416866cd61942fce59dc89ac7660a9578e /ArmPkg/Drivers/ArmCrashDumpDxe | |
parent | 9df2c0a555f1588e35b294838a9ca764bd9c837f (diff) | |
download | edk2-8f5ad634ad4b0593fce0e79f0f743af5f0cf4208.tar.gz edk2-8f5ad634ad4b0593fce0e79f0f743af5f0cf4208.tar.bz2 edk2-8f5ad634ad4b0593fce0e79f0f743af5f0cf4208.zip |
ArmPkg/ArmMmuLib: Extend API to manage memory permissions better
Currently, ArmSetMemoryAttributes () takes a combination of
EFI_MEMORY_xx constants describing the memory type and permission
attributes that should be set on a region of memory. In cases where the
memory type is omitted, we assume that the memory permissions being set
are final, and that existing memory permissions can be discarded.
This is problematic, because we aim to map memory non-executable
(EFI_MEMORY_XP) by default, and only relax this requirement for code
regions that are mapped read-only (EFI_MEMORY_RO). Currently, setting
one permission clears the other, and so code managing these permissions
has to be aware of the existing permissions in order to be able to
preserve them, and this is not always tractable (e.g., the UEFI memory
attribute protocol implements an abstraction that promises to preserve
memory permissions that it is not operating on explicitly).
So let's add an AttributeMask parameter to ArmSetMemoryAttributes(),
which is permitted to be non-zero if no memory type is being provided,
in which case only memory permission attributes covered in the mask will
be affected by the update.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Oliver Smith-Denny <osde@linux.microsoft.com>
Reviewed-by: Michael Kubacki <michael.kubacki@microsoft.com>
Diffstat (limited to 'ArmPkg/Drivers/ArmCrashDumpDxe')
0 files changed, 0 insertions, 0 deletions