With VHE enabled, EL2 uses the EL2&0 translation regime, which is
compatible with the EL1&0 translation regime when it comes to the TCR
configuration register and the page table descriptor.
Given that some CPUs may have VHE force enabled when executing at EL2,
the MMU code needs to be able to deal with this even if it doesn't
enable VHE itself.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Remove the code path for execution at EL3, which just dumps an error.
None of the other code is remotely suitable for execution at EL3, and so
just ASSERT()'ing here is sufficient, and simplifies future changes
related to VHE.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
When VHE is enabled, some pre-existing timer system register specifiers
are redirected to the HYP timer. To access the conventional timer,
special aliases have to be used that end in _EL02.
These aliases are not understood by Clang's internal assembler, so use
the generic mnemonics instead.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
When building OvmfPkg in RELEASE mode in the XCODE5 toolchain, the
ASSERT_EFI_ERROR change prevents this error:
.../MdePkg/Library/UefiMemoryAllocationLib/MemoryAllocationLib.c:141:15:
error: variable 'Status' set but not used [-Werror,-Wunused-but-set-variable]
EFI_STATUS Status;
^
which is currently stopping the build.
When building in RELEASE mode in the CLANGPDB toolchain,the DEBUG macro
change prevents this error:
.../edk2/OvmfPkg/VirtioSerialDxe/VirtioSerial.c:28:22: error:
variable 'EventNames' is not needed and will not be
emitted [-Werror,-Wunneeded-internal-declaration]
STATIC CONST CHAR8 *EventNames[] = {
^
which is currently stopping the build.
CLANGDWARF produces the same error as CLANGPDB above, if
-Wno-unneeded-internal-declaration is removed from its build flags.
With the null DEBUG macro change, this warning suppression
can be removed from CLANGDWARF, which is considered a benefit
as it has the potential to catch real coding errors. This is
done in a subsequent commit.
This commit has the desirable side effect that we no longer require
(and cannot use) explicit `#ifndef MDEPKG_NDEBUG` around items only
used in DEBUG macros. This requires the ArmPkg change made here to
be in the same commit as the MdePkg changes.
Note: In common with existing macros in EDK II, including the pre-existing
and unchanged DEBUG/NOOPT versions of the macros which are modified here,
we use the standard approach of adding `do { ... } while (FALSE)` wrapping
to ensure that the macros behave correctly with surrounding code
(e.g. require a following ';' and do not combine in unexpected ways with
nearby conditionals).
Continuous-integration-options: PatchCheck.ignore-multi-package
Co-authored-by: Mikhail Krichanov <krichanov@ispras.ru>
Signed-off-by: Mike Beaton <mjsbeaton@gmail.com>
Cache maintenance operations by set/way are not broadcast, and operate
on individual architected caches, making them suitable only for
en/disabling cache levels, which is the job of secure firmware, to be
carried out while the CPU in question is not taking part in the
cache coherency protocol.
Managing the clean/dirty state of a memory range can only be done using
cache maintenance by virtual address.
So drop the set/way handling from ArmLib for ARM and AARCH64, as there
is no context where it can be used correctly from EDK2.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
As per the emailed RFC in
https://edk2.groups.io/g/devel/topic/rfc_move/107675828,
this patch moves CompilerIntrinsicsLib from ArmPkg to
MdePkg as this library provides compiler intrinsics, which
are industry standard.
This aligns with the goal of integrating ArmPkg into existing
packages: https://bugzilla.tianocore.org/show_bug.cgi?id=4121.
The newly placed CompilerIntrinsicsLib is added to MdeLibs.dsc.inc
as every DSC that builds ARM/AARCH64 needs this library added. The
old location is removed from every DSC in edk2 in this commit also
to not break bisectability with minimal hoop jumping.
Continuous-integration-options: PatchCheck.ignore-multi-package
Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com>
AsmMacroIoLib.h and AsmMacroIoLibV8.h are used by the
CompilerIntrinsicsLib, which is moving to MdePkg. These
functions provide standard definitions for ARM/AARCH64
assembly code, respectively, and so are moved to the arch
directories in MdePkg to avoid MdePkg having a
dependency on ArmPkg.
Now that the files are in Arm/ and AArch64/ directories,
the filenames are changed to AsmMacroLib.h as we can
distinguish the architecture from the path.
AsmMacroIoLib.inc is unused and so is removed.
Continuous-integration-options: PatchCheck.ignore-multi-package
Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com>
AArch64/ashlti3.S was using AsmMacroIoLib.h which is the ARM version
of these definitions. AsmMacroIoLibV8.h is the AARCH64 version of
these defintions. This patch moves that file to use the proper arch
file.
Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com>
The timer counter register can wrap around and when this happens,
we'll get misbehavior for any MicroSecondDelay() calls. This adds
handling for that.
Signed-off-by: Carsten Haitzler <carsten.haitzler@foss.arm.com>
Drop the pointless constructor in ArmArchTimerLib, which does nothing
useful, especially because AArch64 mandates the presence of the generic
timer, and 32-bit ARM is mostly obsolete these days.
To preserve the existing behavior in DEBUG builds when actually using
the timer, move the ASSERT () on a non-zero frequency to the associated
accessor helper function.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
This library is no longer used, and has been superseded by
ArmPsciResetSystemLib based on ArmMonitorLib. So delete it.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
The SMCCC protocol stipulates the following:
- on AARCH64, 18 arguments can be passed, and 18 values can be returned,
via registers X0-x17;
- on ARM, 8 arguments can be passed, and 8 values can be returned.
This makes ArmSmcLib and ArmHvcLib as implemented currently unsuitable
for use with SMCCC services in general, although for PSCI in particular,
they work fine.
The dependency on both ArmSmcLib and ArmHvcLib is also impractical
because it requires every platform that consumes ArmMonitorLib to
provide resolutions for each, even though most platforms will only ever
need one of these (and the choice is made at compile time)
So let's drop these dependencies, and re-implement the asm helpers from
scratch. Note that the only difference is the actual instruction used
-HVC vs SMC- and so all other code can be shared.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Feature PCDs and fixed-at-build PCDs are identical in concept, but the
latter are accessible from assembler, whereas the former are not. So
convert the SMCCC conduit selection PCD to fixed-at-build so we can make
use of this in a subsequent patch.
Continuous-integration-options: PatchCheck.ignore-multi-package
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
The ARM SMCCC specification stipulates that the conduit for ARM monitor
calls can be determined by taking the conduit for PSCI calls. The
converse is also true, and so we can implement ResetSystemLib for PSCI
using ArmMonitorLib to choose between SMC and HVC instructions.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Fix up a handful of uncrustify infractions and drop the AuditOnly
override for uncrustify so we get the same uncrustify CI coverage as
other packages.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
ArmPsciResetSystemLib has been deprecated since commit
b2c55e7328 in 2017. The
lib itself has not been meaningfully updated in 10 years.
This commit removes the library to complete the deprecation
process and remove confusion over which library to use for
resetting an ARM platform.
Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com>
This patch moves GnuNoteBti.bin from ArmPkg to BaseTools as it
is used during the build by GCC. This removes an unnecessary
dependency on ArmPkg from BaseTools and keeps build related
files in BaseTools.
Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com>
This moves the GccLto files from ArmPkg to BaseTools as they
are files that are only used in the build. This removes an
artificial dependency on ArmPkg from BaseTools and keeps build
related files in BaseTools.
Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com>
This adds logging in failure cases of SetMemoryAttributes. This
is useful generally as if an attribute update fails, code will
typically break, but is added in particular to make debugging
incorrect bootloader usage of the Memory Attribute Protocol. This
patch updates the AARCH64 UpdateRegionMapping.
Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com>
This adds logging in failure cases of SetMemoryAttributes. This
is useful generally as if an attribute update fails, code will
typically break, but is added in particular to make debugging
incorrect bootloader usage of the Memory Attribute Protocol. This
patch updates the ARM32 SetMemoryAttributes.
Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com>
PcdArmArchTimerFreqInHz lets platforms override the architectural timer
frequency, but this really isn't supported in hardware by anything lower
than EL3. And we no longer support running edk2 at EL3.
So drop this Pcd and update ArmArchTimerLib to unconditionally use
ArmGenericTimerGetTimerFreq () instead.
Signed-off-by: Leif Lindholm <quic_llindhol@quicinc.com>
There is a bit of legacy code in ArmArchTimerLib that attempts to program
the generic timer based on a Pcd. This was only ever done for (32-bit)
ARM in case the cpu lacked the Security Extensions (because if they were
there, Secure firmware would be expected to have configured this before
switching to Non-secure state).
We don't support operation without Secure firmware anymore, but also the
code has been incorrectly invoked only on platforms that *do* implement
the Security Extensions since December 2020 and commit 0dd0d42ab5
("ArmPkg: use helper to check for Security extensions in ArmArchTimerLib")
As a result, edk2 has been overriding any programming done by Secure
Firmware on ARM platforms. Which is wrong.
Drop this programming in preparation for deleting the Pcd completely.
Signed-off-by: Leif Lindholm <quic_llindhol@quicinc.com>
Drop logic from the ARM architectural support libraries that can only
execute in EL3 on AArch64 or Monitor mode on 32-bit ARM. While early
32-bit ports (and even some early 64-bit code) included some monitor
logic in EDK2, UEFI per the spec runs in non-secure execution contexts
only, and secure monitor and other secure world duties are usually
delegated to TF-A (Trusted Firmware for the A profile).
Since there are no longer users of this code in EDK2 or the
edk2-platforms tree, let's remove it from the core support libraries.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
The compiler will use this function if it is
left shifting a 128 bit value.
Seen when updating OpenSSL.
Signed-off-by: Jeff Brasen <jbrasen@nvidia.com>
Following the discussion at [1] and as the ArmLib relies on them,
move ArmPkg/Chipset/Aarch64[|Mmu].h files to the MdePkg.
Update the path to correctly include the moved files.
[1] https://edk2.groups.io/g/devel/message/111566
Continuous-integration-options: PatchCheck.ignore-multi-package
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Following the discussion at [1] and as the ArmLib relies on them,
move ArmPkg/Chipset/ArmV7[|Mmu].h files to the MdePkg.
Update the path to correctly include the moved files.
[1] https://edk2.groups.io/g/devel/message/111566
Continuous-integration-options: PatchCheck.ignore-multi-package
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
This reverts commit 32460bb5b1, which is
no longer needed as ArmVirtQemu now has its own special implementation
for ArmMonitorLib.
Continuous-integration-options: PatchCheck.ignore-multi-package
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
ArmVirtQemu may execute at EL2, in which case monitor calls are
generally made using SMC instructions instead of HVC instructions.
Whether or not this is the case can only be decided at runtime, and so
the associated PCD needs to be settable at runtime, if the platform
definition chooses so. This implies a boolean PCD, given that a feature
PCD is build-time configurable only.
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Committed-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Doug Flick [MSFT] <doug.edk2@gmail.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
The DebugPeCoffExtraActionLib implemention in ArmPkg contains some cruft
that dates back to the original RVCT based ARM port, and support for
RVCT was dropped a while ago.
Also drop the handling of Cygwin specific paths, which is highly
unlikely to be still depended upon by anyone.
Tweak the logic so that only two versions of the DEBUG() invocations
remain: one for __GNUC__ when PdbPointer is set, and the fallback that
just prints the image address and the address of the entrypoint.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
mReplaceLiveEntryFunc is a function pointer but assigned as a VOID*
pointer:
mReplaceLiveEntryFunc = *(VOID **)GET_GUID_HOB_DATA (Hob);
This leads to the Visual Studio warning:
nonstandard extension, function/data pointer conversion in
expression
This change updates the assignment to avoid using a data pointer and
defines a type for the function pointer to succinctly and accurately
refer to the type when it is used in the library code.
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Create a helper function to query whether ID_AA64MFR1_EL1 indicates
presence of the Embedded Trace Extension (ETE). This feature is only
visible in AARCH64 state.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Reviewed-by: Pierre Gondois <pierre.gondois@arm.com>
Create a helper function to query whether ID_AA64MFR1_EL1 indicates
presence of the Trace Buffer Extension (TRBE). This feature is only
visible in AARCH64 state.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Reviewed-by: Pierre Gondois <pierre.gondois@arm.com>
Create a helper function to query whether ID_AA64MFR1_EL1 indicates
presence of the Virtualization Host Extensions. This feature is only
visible in AARCH64 state.
Signed-off-by: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Cc: Marcin Juszkiewicz <marcin.juszkiewicz@linaro.org>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Tested-by: Marcin Juszkiewicz <marcin.juszkiewicz@linaro.org>
Jake reports that the IS_ARM_MEMORY_REGION_ATTRIBUTES_SECURE() macro is
no longer accurate since commit 852227a9d5 ("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>
If gST->ConOut is available when Arm's DefaultExceptionHandler is
running, AsciiPrint will get called to attempt to print to ConOut, in
addition to the serial output.
AsciiPrint calls AsciiInternalPrint in UefiLibPrint.c which in turn
calls AllocatePool to allocate a buffer to convert the Ascii input
string to a Unicode string to pass to ConOut->OutputString.
Per the comment on DefaultExceptionHandler, we should not be allocating
memory in the exception handler, as this can cause the exception handler
to fail if we had a memory exception or the system state is such that we
cannot allocate memory.
It has been observed on ArmVirtQemu that exceptions generated in the
memory handling code will fail to output the stack dump and CPU state
that is critical to debugging because the AllocatePool will fail.
This patch fixes the Arm and AARCH64 DefaultExceptionHandlers to not
allocate memory when ConOut is available and instead use stack memory to
convert the Ascii string needed for SerialPortWrite to the Unicode
string needed for ConOut->OutputString. Correspondingly, ArmVirtQemu can
now output the stack dump and CPU state when hitting an exception in
memory code.
Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com>
The OP-TEE secure OS exposes a non-secure memory region for
communication between the secure OS itself and any clients in the
non-secure firmware. This memory is writable by non-secure and is not
used for code only data, and so it should be mapped non-executable.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
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>
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>
The PCD gEfiMdeModulePkgTokenSpaceGuid.PcdEmuVariableNvModeEnable
indicates if a variable driver will emulate the variable NV mode.
This PCD is defined as [PcdsFixedAtBuild, PcdsPatchableInModule,
PcdsDynamic, PcdsDynamicEx].
Some firmware builds may define this PCD as a dynamic PCD and
initialise the value at runtime. Therefore, move the PCD declaration
from the [FixedPcd] section to the [Pcd] section in the platform
boot manager library file PlatformBootManagerLib.inf. Without this
change the build would not succeed.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
The helper that updates live page table entries writes a zero entry,
invalidates the covered address range from the TLBs, and finally writes
the actual entry. This ensures that no TLB conflicts can occur.
Writing the final entry needs to complete before any translations can be
performed, as otherwise, the zero entry, which describes an invalid
translation, may be observed by the page table walker, resulting in a
translation fault. For this reason, the final write is followed by a DSB
barrier instruction.
However, this barrier will not stall the pipeline, and instruction
fetches may still hit this invalid translation, as has been observed and
reported by Oliver. To ensure that the new translation is fully active
before returning from this helper, we have to insert an ISB barrier as
well.
Reported-by: Oliver Steffen <osteffen@redhat.com>
Tested-by: Oliver Steffen <osteffen@redhat.com>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Acked-by: Michael D Kinney <michael.d.kinney@intel.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
The UEFI Shell is a non-active boot option, at the opposite of UiApp.
If no valid boot option is found, UiApp is selected. UiApp requires a
human interaction. When installing a new EDKII image in CIs or when
scripting is required, this is problematic.
If no valid boot option is discovered, add a path to directly go to
the UEFI Shell where the startup.nsh script is automatically executed.
The UEFI Shell is launched after connecting possible devices, but
before the reset that is meant to automatically make them visible.
The new PcdUefiShellDefaultBootEnable must be set to TRUE to enable
this behaviour. The Pcd is set to false by default.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Tested-by: Patrik Berglund <patrik.berglund@arm.com>
ArmCpuInfo uses those to read system registers and other parts of EDK2
may find them useful.
Signed-off-by: Marcin Juszkiewicz <marcin.juszkiewicz@linaro.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
As the ASM_FUNC() macro performs a section switch, the preceding
.balign directive applies the alignment constraint to the current
location in the previous section. As the linker may not merge the
sections in-order, ArmReplaceLiveTranslationEntry() may be left
unaligned.
Replace the explicit invocation of .balign with the ASM_FUNC_ALIGN()
macro, which guarantees the alignment constraint is applied correctly.
To make sure related issues are reliably caught in the future, align the
end of the function before checking the total occupied size. This
ensures crossing a 0x200 boundary will cause a compilation error.
Signed-off-by: Marvin Häuser <mhaeuser@posteo.de>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
__FUNCTION__ is a pre-standard extension that gcc and Visual C++ among
others support, while __func__ was standardized in C99.
Since it's more standard, replace __FUNCTION__ with __func__ throughout
ArmPkg.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
The ELF based toolchains use objcopy to create HII object files, which
contain only a single .hii section. This means no GNU note is inserted
that describes the object as compatible with BTI, even though the lack
of executable code in such an object makes the distinction irrelevant.
However, the linker will not add the note globally to the resulting ELF
executable, and this breaks BTI compatibility.
So let's insert a GNU BTI-compatible ELF note by hand when generating
such object files.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Reviewed-by: Oliver Smith-Denny <osd@smith-denny.com>
The GccLto helper library does not contain any code, as its only purpose
is to pull in other libraries that implement intrinsics to which the
linker's codegen pass may emit calls.
So mark it as BTI compatible, so that the linker does not complain about
unannotated objects.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Reviewed-by: Oliver Smith-Denny <osd@smith-denny.com>
When building with -mbranch-protection=bti, which affects the compiler
codegen only, ensure that the assembler based codegen is aligned with
this, by emitting the BTI C opcode at the start of each exported
function. While most exported functions are not in fact ever called
indirectly, whether or not this is the case is a property of the caller
so annotating every exported function is a reasonable default.
While at it, fix two occurrences in ArmPkg of exported functions that
did not use the ASM_FUNC() macro.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Reviewed-by: Oliver Smith-Denny <osd@smith-denny.com>
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>
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>
Ard Biesheuvel
Mike Beaton
Oliver Smith-Denny
Carsten Haitzler
Leif Lindholm
Jeff Brasen
Pierre Gondois
Michael Kubacki
Sami Mujawar
Marcin Juszkiewicz
Marvin Häuser
Rebecca Cran