2016-06-15 17:54:10 +02:00
|
|
|
/** @file
|
|
|
|
|
|
|
|
Copyright (c) 2015 - 2016, Linaro Ltd. All rights reserved.<BR>
|
|
|
|
|
2019-04-04 01:03:18 +02:00
|
|
|
SPDX-License-Identifier: BSD-2-Clause-Patent
|
2016-06-15 17:54:10 +02:00
|
|
|
|
|
|
|
**/
|
|
|
|
|
2021-04-20 13:00:23 +02:00
|
|
|
#ifndef ARM_MMU_LIB_H_
|
|
|
|
#define ARM_MMU_LIB_H_
|
2016-06-15 17:54:10 +02:00
|
|
|
|
|
|
|
#include <Uefi/UefiBaseType.h>
|
|
|
|
|
|
|
|
#include <Library/ArmLib.h>
|
|
|
|
|
|
|
|
EFI_STATUS
|
|
|
|
EFIAPI
|
|
|
|
ArmConfigureMmu (
|
|
|
|
IN ARM_MEMORY_REGION_DESCRIPTOR *MemoryTable,
|
|
|
|
OUT VOID **TranslationTableBase OPTIONAL,
|
|
|
|
OUT UINTN *TranslationTableSize OPTIONAL
|
|
|
|
);
|
|
|
|
|
|
|
|
VOID
|
|
|
|
EFIAPI
|
|
|
|
ArmReplaceLiveTranslationEntry (
|
2022-09-24 18:26:19 +02:00
|
|
|
IN UINT64 *Entry,
|
|
|
|
IN UINT64 Value,
|
|
|
|
IN UINT64 RegionStart,
|
|
|
|
IN BOOLEAN DisableMmu
|
2016-06-15 17:54:10 +02:00
|
|
|
);
|
|
|
|
|
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>
2023-06-02 17:17:36 +02:00
|
|
|
/**
|
|
|
|
Set the requested memory permission attributes on a region of memory.
|
|
|
|
|
|
|
|
BaseAddress and Length must be aligned to EFI_PAGE_SIZE.
|
|
|
|
|
|
|
|
If Attributes contains a memory type attribute (EFI_MEMORY_UC/WC/WT/WB), the
|
|
|
|
region is mapped according to this memory type, and additional memory
|
|
|
|
permission attributes (EFI_MEMORY_RP/RO/XP) are taken into account as well,
|
|
|
|
discarding any permission attributes that are currently set for the region.
|
|
|
|
AttributeMask is ignored in this case, and must be set to 0x0.
|
|
|
|
|
|
|
|
If Attributes contains only a combination of memory permission attributes
|
|
|
|
(EFI_MEMORY_RP/RO/XP), each page in the region will retain its existing
|
|
|
|
memory type, even if it is not uniformly set across the region. In this case,
|
|
|
|
AttributesMask may be set to a mask of permission attributes, and memory
|
|
|
|
permissions omitted from this mask will not be updated for any page in the
|
|
|
|
region. All attributes appearing in Attributes must appear in AttributeMask
|
|
|
|
as well. (Attributes & ~AttributeMask must produce 0x0)
|
|
|
|
|
|
|
|
@param[in] BaseAddress The physical address that is the start address of
|
|
|
|
a memory region.
|
|
|
|
@param[in] Length The size in bytes of the memory region.
|
|
|
|
@param[in] Attributes Mask of memory attributes to set.
|
|
|
|
@param[in] AttributeMask Mask of memory attributes to take into account.
|
|
|
|
|
|
|
|
@retval EFI_SUCCESS The attributes were set for the memory region.
|
|
|
|
@retval EFI_INVALID_PARAMETER BaseAddress or Length is not suitably aligned.
|
|
|
|
Invalid combination of Attributes and
|
|
|
|
AttributeMask.
|
|
|
|
@retval EFI_OUT_OF_RESOURCES Requested attributes cannot be applied due to
|
|
|
|
lack of system resources.
|
|
|
|
|
|
|
|
**/
|
2017-03-01 17:31:40 +01:00
|
|
|
EFI_STATUS
|
|
|
|
ArmSetMemoryAttributes (
|
|
|
|
IN EFI_PHYSICAL_ADDRESS BaseAddress,
|
|
|
|
IN UINT64 Length,
|
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>
2023-06-02 17:17:36 +02:00
|
|
|
IN UINT64 Attributes,
|
|
|
|
IN UINT64 AttributeMask
|
2017-03-01 17:31:40 +01:00
|
|
|
);
|
|
|
|
|
2021-04-20 13:00:23 +02:00
|
|
|
#endif // ARM_MMU_LIB_H_
|