summaryrefslogtreecommitdiffstats
path: root/ArmPkg/Library/ArmMmuLib/Arm
Commit message (Collapse)AuthorAgeFilesLines
* ArmPkg/ArmMmuLib: Drop buggy secure memory type checkArd Biesheuvel2023-09-121-2/+0
| | | | | | | | | | | | | | | Jake reports that the IS_ARM_MEMORY_REGION_ATTRIBUTES_SECURE() macro is no longer accurate since commit 852227a9d52e3cb9 ("ArmPkg/Mmu: Remove handling of NONSECURE memory regions"). Fortunately, it only affects the NS bit in level 1 short descriptors, which is ignored when executing in non-secure mode. And given that running UEFI in the secure world is not a use case we aim to support, let's just drop this logic altogether. Reported-by: Jake Garver <jake@nvidia.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
* ArmPkg: Drop individual memory permission helpersArd Biesheuvel2023-06-271-104/+0
| | | | | | | | | | Now that we have a sane API to set and clear memory permissions that works the same on ARM and AArch64, we no longer have a need for the individual set/clear no-access/read-only/no-exec helpers so let's drop them. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
* ArmPkg/ArmMmuLib: Extend API to manage memory permissions betterArd Biesheuvel2023-06-261-13/+79
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* ArmPkg/ArmMmuLib: Introduce region types for RO/XP WB cached memoryArd Biesheuvel2023-03-161-0/+16
| | | | | | | | | | | | | | | | To prepare for the enablement of booting EFI with the SCTLR.WXN control enabled, which makes all writeable memory regions non-executable by default, introduce a memory type that we will use to describe the flash region that carries the SEC and PEIM modules that execute in place. Even if these are implicitly read-only due to the ROM nature, they need to be mapped with read-only attributes in the page tables to be able to execute from them. Also add the XP counterpart which will be used for all normal DRAM right at the outset. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
* ArmPkg/Mmu: Remove handling of NONSECURE memory regionsArd Biesheuvel2023-03-161-27/+6
| | | | | | | | | | | | Non-secure memory is a distinction that only matters when executing code in the secure world that reasons about the secure vs non-secure address spaces. EDK2 was not designed for that, and the AArch64 version of the MMU handling library already treats them as identical, so let's just drop the ARM memory region types that mark memory as 'non-secure' explicitly. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
* ArmPkg/ArmMmuLib: Avoid splitting block entries if possibleArd Biesheuvel2023-03-161-0/+11
| | | | | | | | | | | | | | | | | Currently, the ARM MMU page table logic will break down any block entry that overlaps with the region being mapped, even if the block entry in question is using the same attributes as the new region. This means that creating a non-executable mapping inside a region that is already mapped non-executable at a coarser granularity may trigger a call to AllocatePages (), which may recurse back into the page table code to update the attributes on the newly allocated page tables. Let's avoid this, by preserving the block entry if it already covers the region being mapped with the correct attributes. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
* ArmPkg/ArmMmuLib: Implement EFI_MEMORY_RP using access flagArd Biesheuvel2023-03-161-0/+48
| | | | | | | | | | | Implement support for read-protected memory by wiring it up to the access flag in the page table descriptor. The resulting mapping is implicitly non-writable and non-executable as well, but this is good enough for implementing this attribute, as we never rely on write or execute permissions without read permissions. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
* ArmPkg/ArmMmuLib ARM: Clear individual permission bitsArd Biesheuvel2023-03-161-13/+81
| | | | | | | | | | | | | | | | | Currently, the MMU code that is supposed to clear the RO or XP attributes from a region just clears both unconditionally. This approximates the desired behavior to some extent, but it does mean that setting the RO bit first on a code region, and then clearing the XP bit results both RO and XP being cleared, and we end up with writable code, and avoiding that is the point of all these protections. Once we introduce RP support, this will only get worse, so let's fix this up, by reshuffling the attribute update code to take the entry mask from the caller, and use the mask to preserve other attributes when clearing RO or XP. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
* ArmPkg/ArmMmuLib ARM: Isolate the access flag from AP maskArd Biesheuvel2023-03-162-2/+11
| | | | | | | | | | | Split the ARM permission fields in the short descriptors into an access flag and AP[2:1] as per the recommendation in the ARM ARM. This makes the access flag available separately, which allows us to implement EFI_MEMORY_RP memory analogous to how it will be implemented for AArch64. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
* ArmPkg/ArmMmuLib ARM: Split off XN page descriptor bit from type fieldArd Biesheuvel2023-03-161-6/+6
| | | | | | | | | | | With large page support out of the picture, we can treat bits 1 and 0 of the page descriptor as individual valid and XN bits, instead of treating XN as a page type. Doing so aligns the handling of the attribute with the section descriptor layout, as well as the XN handling on AArch64, and this is beneficial for maintainability. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
* ArmPkg/ArmMmuLib ARM: Remove half baked large page supportArd Biesheuvel2023-03-163-6/+5
| | | | | | | | | | | | | | | | | | Large page support on 32-bit ARM is essentially a glorified contiguous bit where 16 consecutive entries describing a contiguous range with the same attributes are presented in a way that permits the TLB to cache its translation with a single entry. This was never wired up completely, and does not add a lot of value in EFI, where the page granularity is 4k and we expect to be able to set RO and XP permissions on individual pages. Given that large page support complicates the handling of the XN bit at the page level (which is in a different place depending on whether the page is small or large), let's just rip it out. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
* ArmPkg: Remove RVCT supportRebecca Cran2022-05-131-26/+0
| | | | | | | | RVCT is obsolete and no longer used. Remove support for it. Signed-off-by: Rebecca Cran <quic_rcran@quicinc.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
* ArmPkg: Apply uncrustify changesMichael Kubacki2021-12-073-177/+209
| | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3737 Apply uncrustify changes to .c/.h files in the ArmPkg package Cc: Andrew Fish <afish@apple.com> Cc: Leif Lindholm <leif@nuviainc.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com> Reviewed-by: Andrew Fish <afish@apple.com>
* ArmPkg: Correct small typosPierre Gondois2021-04-281-2/+2
| | | | | | | | | | | | | The 'cspell' CI test detected some small typos in ArmPkg. Correct them. Cc: Bret Barkelew <bret.barkelew@microsoft.com> Cc: Sean Brogan <sean.brogan@microsoft.com> Cc: Leif Lindholm <leif@nuviainc.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Sami Mujawar <sami.mujawar@arm.com> Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
* ArmPkg: Fix Ecc error 5007 in ArmMmuLibPierre Gondois2021-01-061-1/+3
| | | | | | | | | This patch fixes the following Ecc reported error: There should be no initialization of a variable as part of its declaration Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
* ArmPkg: Fix Ecc error 3002 in ArmMmuLibPierre Gondois2021-01-061-15/+15
| | | | | | | | | This patch fixes the following Ecc reported error: Non-Boolean comparisons should use a compare operator (==, !=, >, < >=, <=) Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
* ArmPkg/ArmMmuLib: Explicitly cast UINT32 data conversionsMichael Kubacki2020-10-222-4/+4
| | | | | | | | | | | | | | | | | | | | | | | REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2835 There's several occurrences of a UINT64 or an EFI_PHYSICAL_ADDRESS being assigned to a UINT32 value in ArmMmuLib. These result in warning C4244 in VS2019: warning C4244: '=': conversion from 'UINT64' to 'UINT32', possible loss of data warning C4244: '=': conversion from 'EFI_PHYSICAL_ADDRESS' to 'UINT32', possible loss of data This change explicitly casts the values to UINT32. These can be reproduced with the following build command: build -b DEBUG -a ARM -t VS2019 -p ArmPkg/ArmPkg.dsc -m ArmPkg/Library/ArmMmuLib/ArmMmuBaseLib.inf Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
* ArmPkg/ArmMmuLib ARM: drop memory type check for page tablesArd Biesheuvel2020-03-051-18/+2
| | | | | | | | | | We already expect normal memory to be mapped writeback cacheable if EDK2 itself is to make use of it, so doing an early sanity check on the memory type of the allocation that the page tables happened to land in isn't very useful. So let's drop it. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Leif Lindholm <leif@nuviainc.com>
* ArmPkg/ArmMmuLib ARM: simplify assignment of TTBR0 system registerArd Biesheuvel2020-03-051-1/+1
| | | | | | | | | | | | | | | The expression passed into ArmSetTTBR0 () in ArmConfigureMmu() is sub-optimal at several levels: - TranslationTable is already aligned, and if it wasn't, doing it here wouldn't help - TTBRAttributes is guaranteed not to have any bits set outside of the 0x7f mask, so the mask operation is pointless as well, - an additional (UINTN) cast for good measure is also not needed. So simplify the expression. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Leif Lindholm <leif@nuviainc.com>
* ArmPkg/ArmMmuLib ARM: cache-invalidate initial page table entriesArd Biesheuvel2020-03-051-14/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the ARM version of ArmMmuLib, we are currently relying on set/way invalidation to ensure that the caches are in a consistent state with respect to main memory once we turn the MMU on. Even if set/way operations were the appropriate method to achieve this, doing an invalidate-all first and then populating the page table entries creates a window where page table entries could be loaded speculatively into the caches before we modify them, and shadow the new values that we write there. So let's get rid of the blanket clean/invalidate operations, and instead, invalidate each page table right after allocating it, and each section entry after it is updated (to address all the little corner cases that the ARMv7 spec permits), and invalidate sets of level 2 entries in blocks, using the generic invalidation routine from CacheMaintenanceLib On ARMv7, cache maintenance may be required also when the MMU is enabled, in case the page table walker is not cache coherent. However, the code being updated here is guaranteed to run only when the MMU is still off, and so we can disregard the case when the MMU and caches are on. Since the MMU and D-cache are already off when we reach this point, we can drop the MMU and D-cache disables as well. Maintenance of the I-cache is unnecessary, since we are not modifying any code, and the installed mapping is guaranteed to be 1:1. This means we can also leave it enabled while the page table population code is running. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Leif Lindholm <leif@nuviainc.com>
* ArmPkg/ArmMmuLib ARM: use AllocateAlignedPages() for alignmentArd Biesheuvel2020-03-051-9/+10
| | | | | | | | | | | | Instead of overallocating memory and align the resulting base address manually, use the AllocateAlignedPages () helper, which achieves the same, and might even manage that without leaking a chunk of memory of the same size as the allocation itself. While at it, fix up a variable declaration in the same hunk, and drop a comment whose contents add nothing to the following line of code. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* ArmPkg/ArmMmuLib ARM: split ArmMmuLibCore.c into core and update codeArd Biesheuvel2020-03-053-434/+467
| | | | | | | | | | | | | | | | | | | Unlike the AArch64 implementation of ArmMmuLib, which combines the initial page table population code with the code that runs at later stages to manage permission attributes in the page tables, ARM uses two completely separate sets of routines for this. Since ArmMmuLib is a static library, we can prevent duplication of this code between different users, which usually only need one or the other. (Note that LTO should also achieve the same.) This also makes it easier to reason about modifying the cache maintenance handling, and replace the set/way ops with by-VA ops, since the code that performs the set/way ops only executes when the MMU is still off. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Leif Lindholm <leif@nuviainc.com>
* ArmPkg/ArmMmuLib ARM: remove dummy constructorArd Biesheuvel2020-03-051-9/+0
| | | | | | | | Make the CONSTRUCTOR define in the .INF AARCH64 only, so we can drop the empty stub that exists for ARM. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Leif Lindholm <leif@nuviainc.com>
* ArmPkg: Fix various typosAntoine Cœur2019-07-041-1/+1
| | | | | | | Fix various typos in ArmPkg. Signed-off-by: Coeur <coeur@gmx.fr> Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
* ArmPkg: Replace BSD License with BSD+Patent LicenseMichael D Kinney2019-04-093-21/+3
| | | | | | | | | | | | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=1373 Replace BSD 2-Clause License with BSD+Patent License. This change is based on the following emails: https://lists.01.org/pipermail/edk2-devel/2019-February/036260.html https://lists.01.org/pipermail/edk2-devel/2018-October/030385.html RFCs with detailed process for the license change: V3: https://lists.01.org/pipermail/edk2-devel/2019-March/038116.html V2: https://lists.01.org/pipermail/edk2-devel/2019-March/037669.html V1: https://lists.01.org/pipermail/edk2-devel/2019-March/037500.html Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
* ArmPkg/ArmMmuLib ARM: trim high memory regions instead of rejecting themArd Biesheuvel2019-01-281-1/+2
| | | | | | | | | | | | | | | ArmSetMemoryAttributes() still chokes in some cases, i.e., when the length of the region exceeds 4 GB, the subtraction overflows, which results in the region being misidentified as being 32-bit addressable. Let's update the logic to trim the length to what we can address with 32 bits. This fixes the issue, and also deals with the issue where an entire region is disregarded if part of it exceeds beyond what we can map with 32 bits. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
* ArmPkg/ArmMmuLib ARM: disregard high memory when setting permissionsArd Biesheuvel2019-01-141-0/+4
| | | | | | | | | | | Ignore calls to ArmSetMemoryAttributes () when the region described is outside of the 32-bit addressable range. This memory is not mapped in the first place, and the current code does not deal with the high bits correctly, resulting in hangs. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
* ArmPkg/ArmMmuLib ARM: fix thinko in second level page table handlingArd Biesheuvel2019-01-131-2/+2
| | | | | | | | | | | | | | | | | PopulateLevel2PageTable () is invoked for [parts of] mappings that start or end on a non-1 MB aligned address (or both). The size of the mapping depends on both the start address modulo 1 MB and the length of the mapping, but the logic that calculates this size is flawed: subtracting 'start address modulo 1 MB' could result in a negative value for the remaining length, which is obviously wrong. So instead, take either RemainLength, or the rest of the 1 MB block, whichever is smaller. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org> Tested-by: Eugene Cohen <eugene@hp.com>
* ArmPkg/ArmMmuLib ARM: add missing support for non-shareable cached mappingsArd Biesheuvel2019-01-131-0/+13
| | | | | | | | | | | Commit 829633e3a82 ("ArmPkg/ArmMmuLib: Add new attribute WRITE_BACK_NONSHAREABLE") introduced support for non-shareable cached mappings to the AArch64 version of ArmMmuLib, but the ARM version was left behind, so fix that. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
* ArmPkg/ArmMmuLib ARM: handle unmapped sections when updating permissionsArd Biesheuvel2018-12-031-2/+6
| | | | | | | | | | | | | The ARM ArmMmuLib code currently does not take into account that setting permissions on a region should take into account that a region may not be mapped yet to begin with. So when updating a section descriptor whose old value is zero, pass in the address explicitly. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
* ArmPkg/ArmMmuLib ARM: fix Mva to use idx instead of table baseChris Co2018-06-211-1/+1
| | | | | | | | | | | | | Mva address calculation should use the left-shifted current section index instead of the left-shifted table base address. Using the table base address here has the side-effect of potentially causing an access violation depending on the base address value. Cc: Leif Lindholm <leif.lindholm@linaro.org> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Christopher Co <christopher.co@microsoft.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* ArmPkg/ArmMmuLib ARM: assume page tables are in writeback cacheable memoryArd Biesheuvel2018-06-211-11/+3
| | | | | | | | | | | | Given that these days, our ARM port only supports ARMv7 and later, we can assume that the page table walker's memory accesses are cache coherent, and so there is no need to perform cache maintenance. It does require the page tables themselves to reside in memory mapped as writeback cacheable so ASSERT() that this is the case. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
* ArmPkg/ArmMmuLib ARM: remove cache maintenance of block mapping contentsArd Biesheuvel2018-06-211-12/+0
| | | | | | | | | | | | | | | | | | | Peculiarly enough, the current page table manipulation code takes it upon itself to write back and invalidate the memory contents covered by page and section mappings when their memory attributes change. It is not generally the case that data must be written back when such a change occurs, even when switching from cacheable to non-cacheable attributes, and in some cases, it is actually causing problems. (The cache maintenance is also performed on the PCIe MMIO regions as they get mapped by the PCI bus driver, and under virtualization, each cache maintenance operation on an emulated MMIO region triggers a round trip to the host and back) So let's just drop this code. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
* ArmPkg/ArmMmuLib ARM: fix page size granularity in initial MMU settingMichael Zimmermann2017-12-201-17/+23
| | | | | | | | | | | | | | | | | From what I can see this bug dates back to the commit from 2011 where support for this was added: 2cf4b60895f8a The first problem is that PopulateLevel2PageTable overflows the translation table buffer because it doesn't verify that the size actually fits within one level 2 page table. The second problem is that the loop in FillTranslationTable doesn't care about the PhysicalBase or the RemainLength and always substracts one section size from RemainLength. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Michael Zimmermann <sigmaepsilon92@gmail.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* ArmPkg/ArmMmuLib ARM: implement memory permission control routinesArd Biesheuvel2017-03-071-4/+6
| | | | | | | | | | | | | | | | | Now that we have the prerequisite functionality available in ArmMmuLib, wire it up into ArmSetMemoryRegionNoExec, ArmClearMemoryRegionNoExec, ArmSetMemoryRegionReadOnly and ArmClearMemoryRegionReadOnly. This is used by the non-executable stack feature that is configured by DxeIpl. NOTE: The current implementation will not combine RO and XP attributes, i.e., setting/clearing a region no-exec will unconditionally clear the read-only attribute, and vice versa. Currently, we only use ArmSetMemoryRegionNoExec(), so for now, we should be able to live with this. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
* ArmPkg/ArmMmuLib: remove VirtualMask arg from ArmSetMemoryAttributesArd Biesheuvel2017-03-071-17/+4
| | | | | | | | | | | | | We no longer make use of the ArmMmuLib 'feature' to create aliased memory ranges with mismatched attributes, and in fact, it was only wired up in the ARM version to begin with. So remove the VirtualMask argument from ArmSetMemoryAttributes()'s prototype, and remove the dead code that referred to it. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
* ArmPkg: move ARM version of SetMemoryAttributes to ArmMmuLibArd Biesheuvel2017-03-071-0/+397
| | | | | | | | | | | | | | | ... where it belongs, since AARCH64 already keeps it there, and non DXE users of ArmMmuLib (such as DxeIpl, for the non-executable stack) may need its functionality as well. While at it, rename SetMemoryAttributes to ArmSetMemoryAttributes, and make any functions that are not exported STATIC. Also, replace an explicit gBS->AllocatePages() call [which is DXE specific] with MemoryAllocationLib::AllocatePages(). Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
* ArmPkg/ArmMmuLib: use correct return type for exported functionsArd Biesheuvel2017-03-071-8/+9
| | | | | | | | | | | | | | The routines ArmConfigureMmu(), SetMemoryAttributes() [*] and the various set/clear read-only/no-exec routines are declared as returning EFI_STATUS in the respective header files, so align the definitions with that. * SetMemoryAttributes() is declared in the wrong header (and defined in ArmMmuLib for AARCH64 and in CpuDxe for ARM) Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
* ArmPkg: introduce base ArmMmuLib implementationArd Biesheuvel2016-07-073-0/+519
This base library encapsulates the MMU manipulation routines that have been factored out of ArmLib. The functionality covers initial creation of the 1:1 mapping in the page tables, and remapping regions to change permissions or cacheability attributes. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>