The PERFORMANCE_DESCRIBE_FASTCHANNEL Scmi command is available
since SCMI v2.0 and allows to query information about the supported
fast-channels of the Scmi performance protocol.
Add support for this command.
Also move SCMI_MESSAGE_ID_PERFORMANCE enum definition up in the file
to use it in SCMI_PERFORMANCE_DESCRIBE_FASTCHANNEL function
declaration.
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Rename PERFORMANCE_PROTOCOL_VERSION to reflect the different
versions of the protocol. The macro is neither used in edk2 nor
in edk2-platforms.
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
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>
GetNextEntryAttribute() is currently applying a 64-bit mask
(TT_ATTRIBUTES_MASK) to a 32-bit descriptor value (EntryType).
The original descriptor was 64 bits containing the upper and
lower attributes which are included in TT_ATTRIBUTES_MASK.
The PrevEntryAttribute parameter is also a UINT32, but passed to
PageAttributeToGcdAttribute() for a UINT64 parameter where the
function checks masks in the upper 32 bits of the integer value:
PageAttributeToGcdAttribute (*PrevEntryAttribute)
...
STATIC
UINT64
PageAttributeToGcdAttribute (
IN UINT64 PageAttributes
)
...
if ((PageAttributes & (TT_PXN_MASK | TT_UXN_MASK)) != 0) {
GcdAttributes |= EFI_MEMORY_XP;
}
...
#define TT_PXN_MASK BIT53
#define TT_UXN_MASK BIT54 // EL1&0
This change removes UINT32 intermediary values. For EntryType,
eliminating an unncessary cast. For EntryAttribute, preserving the
upper and lower attributes for evaluation in
PageAttributeToGcdAttribute().
This also resolves the following compiler warning previously present
on Visual Studio for the assignment to the previously 32-bit local
variables.
'=': conversion from 'UINT64' to 'UINT32', possible loss of data
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
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>
Add EFI_NOT_READY return if the CPU can not be enabled because the
processor is already on.
This can occur in normal use if the CPU is still being turned off from
a previous call when this is called again.
Signed-off-by: Jeff Brasen <jbrasen@nvidia.com>
Reviewed-by: Rebecca Cran <rebecca@bsdio.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>
PcdArmArchTimerHypVirtIntrNum, defaults to 28 as defined in Arm's
Base System Architecture (current version DEN0094C 1.0C).
Relevant for systems implementing FEAT_VHE, added in ARMv8.1.
Signed-off-by: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Leif Lindholm <quic_llindhol@quicinc.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.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>
I am moving this command outside of EDK2.
This reverts commit 2c2cb23528.
Signed-off-by: Marcin Juszkiewicz <marcin.juszkiewicz@linaro.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
The top two bits of the Extended BIOS ROM Size field indicates the unit
used for the remaining 14 bits. If the size is greater than 16GB, the
unit is gigabytes.
The test for this uses the local BiosPhysicalSize variable, which is a
UINTN, meaning that when building for ARM/CLANGDWARF we have a
tautological constant comparison, which the toolchain flags now we've
stopped disabling that warning.
So switch the BiosPhysicalSize variable to UINT64.
Signed-off-by: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
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>
Much of the MMU logic was written without function headers. This patch
adds function headers where absent and updates function headers which
do not match the EDK2 standard.
Signed-off-by: Taylor Beebe <t@taylorbeebe.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
There are ASSERTs present in the MMU logic to ensure various
functions return successfully, but these ASSERTs may be ignored
on release builds causing unsafe behavior. This patch updates
the logic to handle unexpected return values and branch safely.
Signed-off-by: Taylor Beebe <t@taylorbeebe.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
This patch updates the GetMemoryRegion() function to handle the case
where there is no mapping for the requested address.
The original logic for the ARM would hit an ASSERT after
GetMemoryRegionPage() returned EFI_SUCCESS but did not update The
RegionLength parameter.
The original logic for the AARCH64 would never initialize the
RegionLength parameter to zero and return EFI_SUCCESS after
traversing an unknown number of pages.
To fix this, update the logic for both architecture to return
EFI_NO_MAPPING if the BaseAddress being checked is unmapped.
Signed-off-by: Taylor Beebe <t@taylorbeebe.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
This patch applies Uncrustify to the following files:
ArmPkg/Drivers/MmCommunicationPei/MmCommunicationPei.c
ArmPkg/Include/IndustryStandard/ArmStdSmc.h
Signed-off-by: Taylor Beebe <t@taylorbeebe.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4464
This change introduced the MM communicate support in PEI phase for ARM
based platforms. Similar to the DXE counterpart, `PcdMmBufferBase` is
used as communicate buffer and SMC will be invoked to communicate to
TrustZone when MMI is requested.
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Co-authored-by: Ronny Hansen <hansen.ronny@microsoft.com>
Co-authored-by: Shriram Masanamuthu Chinnathurai <shriramma@microsoft.com>
Co-authored-by: Preshit Harlikar <pharlikar@microsoft.com>
Signed-off-by: Kun Qin <kuqin@microsoft.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
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>
Now that ArmSetMemoryAttributes() permits a mask to be provided, we can
simplify the implementation the UEFI memory attribute protocol
substantially, and just pass on the requested mask to be set or cleared
directly.
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>
Implement the newly defined PPI that permits the PEI core and DXE IPL to
manage memory permissions on ranges of DRAM, for doing things like
mapping the stack non-executable, or granting executable permissions to
shadowed PEIMs.
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>
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>
They are useful for those platforms where SMC SiP calls exist.
Signed-off-by: Marcin Juszkiewicz <marcin.juszkiewicz@linaro.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Uncrustify checks are too rigid, making them counter-productive:
- it leads to code that is arguably harder to parse visually (e.g.,
the changes to ArmPkg/Include/Chipset/AArch64Mmu.h in commit
429309e0c6)
- it forces indentation-only changes to code in the vicinity of actual
changes, making the code history more bloated than necessary (see
commit 7f198321ee for an example)
- finding out from the web UI what exactly Uncrustify objected to is not
straight-forward.
So let's enable AuditMode for ArmPkg, so that interested parties can see
the uncrustify recommendations if desired, but without preventing the
changes from being merged. This leaves it at the discretion of the
ArmPkg maintainers to decide which level of conformance is required.
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: "Kinney, Michael D" <michael.d.kinney@intel.com>
Cc: Michael Kubacki <mikuback@linux.microsoft.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
The ArmGicAcknowledgeInterrupt () returns the value returned by the
Interrupt Acknowledge Register and the InterruptID separately in an out
parameter.
The function documents the following: 'InterruptId is returned
separately from the register value because in the GICv2 the register
value contains the CpuId and InterruptId while in the GICv3 the register
value is only the InterruptId.'
This function skips setting the InterruptId in the out parameter for
GICv3. Although the return value from the function is the InterruptId
for GICv3, this breaks the function usage model as the caller expects
the InterruptId in the out parameter for the function. e.g. The caller
may end up using the InterruptID which could potentially be an
uninitialised variable value.
Therefore, set the InterruptID in the function out parameter for GICv3
as well.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
According to the GIC architecture version 3 and 4 specification, the
maximum number of INTID bits supported in the CPU interface is 24.
Considering this the RegShift variable is not required to be more than 8
bits. Therefore, make the RegShift variable type to UINT8. Also add
necessary typecasts when calculating the RegOffset and RegShift values.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
GICD_SGIR is a 32-bit register, of which INTID is bits [3:0] and Bits
[14:4] is RES0. Since SgiId parameter in the function ArmGicSendSgiTo ()
is UINT8, mask unused bits of SgiId before writing to the GICD_SGIR
register to prevent accidental setting of the RES0 bits.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
The IrqInterruptHandler () and ExitBootServicesEvent () function
declarations were unused. Therefore, remove these declarations.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
The EIOR register of the Gic CPU interface is a 32 bit register.
However, the HARDWARE_INTERRUPT_SOURCE used to represent the interrupt
source (Interrupt ID) is typedefed as UINTN, see
EmbeddedPkg\Include\Protocol\HardwareInterrupt.h
Therfore, typecast the interrupt ID (Source) value to UINT32 before
setting the EOIR register. Also, add an assert to check that the value
does not exceed 32 bits.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Although the maximum interrupt ID on GicV2 is 10bit and for GicV3/4 is
24bit, and that the IAR and EOIR registers of the Gic CPU interface are
32 bit; the typedef HARDWARE_INTERRUPT_SOURCE is defined as UINTN in
EmbeddedPkg\Include\Protocol\HardwareInterrupt.h
Therefore, use UINTN for Gic Interrupt variables and use appropriate
typecasts wherever needed.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
The CPU Interface Identification Register (GICC_IIDR) is a 32-bit
register. Since ArmGicGetInterfaceIdentification () returns the value
read from the GICC_IIDR register, update the return type for this
function to UINT32.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
According to edk2 coding standard specification, Non-Boolean comparisons
must use a compare operator (==, !=, >, < >=, <=). See Section 5.7.2.1
at https://edk2-docs.gitbook.io/
edk-ii-c-coding-standards-specification/5_source_files/ 57_c_programming
Therefore, fix the comparison in ArmGicEnableDistributor()
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
The Software Generated Interrupt Register (GICD_SGIR) is a 32 bit
register with the following bit assignment:
TargetListFilter, bits [25:24]
CPUTargetList, bits [23:16]
NSATT, bit [15]
SGIINTID, bits [3:0]
Therefore, modify the TargetListFilter, CPUTargetList, SGI Interrupt ID
parameters of the ArmGicSendSgiTo () to use UINT8 instead of INTN.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
The data type used by variables representing the
GicInterruptInterfaceBase has been inconsistently used in the ArmGic
driver and the library. The PCD defined for the GIC Interrupt interface
base address is UINT64. However, the data types for the variables used
is UINTN, INTN, and at some places UINT32.
Therefore, update the data types to use UINTN and add necessary
typecasts when reading values from the PCD. This should then be
consistent across AArch32 and AArch64 builds.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
The data type used by variables representing the GicDistributorBase has
been inconsistently used in the ArmGic driver and the library. The PCD
defined for the GIC Distributor base address is UINT64. However, the
data types for the variables used is UINTN, INTN, and at some places
UINT32.
Therefore, update the data types to use UINTN and add necessary
typecasts when reading values from the PCD. This should then be
consistent across AArch32 and AArch64 builds.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
The GIC v2 base addresses can be 64bit, don't limit to 32 on 64bit
machines.
Signed-off-by: Neil Jones <neil.jones@blaize.com>
Reviewed-by: Pedro Falcato <pedro.falcato@gmail.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
The DXE core implementation of PcdDxeNxMemoryProtectionPolicy already
contains an assertion that EfiConventionalMemory and EfiBootServicesData
are subjected to the same policy when it comes to the use of NX
permissions. The reason for this is that we may otherwise end up with
unbounded recursion in the page table code, given that allocating a page
table would then involve a permission attribute change, and this could
result in the need for a block entry to be split, which would trigger
the allocation of a page table recursively.
For the same reason, a shortcut exists in ApplyMemoryProtectionPolicy()
where, instead of setting the memory attributes unconditionally, we
compare the NX policies and avoid touching the page tables if they are
the same for the old and the new memory types. Without this shortcut, we
may end up in a situation where, as the CPU arch protocol DXE driver is
ramping up, the same unbounded recursion is triggered, due to the fact
that the NX policy for EfiConventionalMemory has not been applied yet.
To break this cycle, let's remap all EfiConventionalMemory regions
according to the NX policy for EfiBootServicesData before exposing the
CPU arch protocol to the DXE core and other drivers. This ensures that
creating EfiBootServicesData allocations does not result in memory
attribute changes, and therefore no recursion.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.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>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4463
When the AARCH64 CpuDxe attempts to SyncCacheConfig() with the GCD, it
collects the page attributes as:
EntryAttribute = Entry & TT_ATTR_INDX_MASK
However, TT_ATTR_INDX_MASK only masks the cacheability attributes and
drops the memory protections attributes. Importantly, it also drops the
TT_AF (access flag) which is now wired up in EDK2 to represent
EFI_MEMORY_RP, so by default all SystemMem pages will report as
EFI_MEMORY_RP to the GCD. The GCD currently drops that silently, because
the Capabilities field in the GCD does not support EFI_MEMORY_RP by
default.
However, some ranges may support EFI_MEMORY_RP and incorrectly mark
those ranges as read protected. In conjunction with another change on
the mailing list (see: https://edk2.groups.io/g/devel/topic/98505340),
this causes an access flag fault incorrectly. See the linked BZ below
for full details.
This patch exposes all memory protections attributes to the GCD layer so
it can correctly set pages as EFI_MEMORY[RP|XP|RO] when it initially
syncs.
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Cc: Taylor Beebe <t@taylorbeebe.com>
Cc: Sean Brogan <sean.brogan@microsoft.com>
Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Michael Kubacki <michael.kubacki@microsoft.com>
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>
App goes through ID_AA64*_EL1 system registers and decode their values.
Signed-off-by: Marcin Juszkiewicz <marcin.juszkiewicz@linaro.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.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>
ArmCpuInfo needs to be able to read ID_AA64ISAR2_EL1 system register.
Older toolchains do not know it.
Same solution as one for QEMU:
https://www.mail-archive.com/qemu-devel@nongnu.org/msg929586.html
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>
With the current ASM_FUNC() macro, there is no good way to declare an
alignment constraint for a function. As ASM_FUNC() switches sections,
declaring the constraint before the macro invocation applies it to the
current location in the previous section. Declaring the constraint after
the macro invocation lets the function label point to the location prior
to alignment. Depending on toolchain behaviour, this may cause the label
to point to alignment padding preceding the actual function definition.
To address these issues, introduce the ASM_FUNC_ALIGN() macro, which
declares the alignment constraint right before the function label.
Signed-off-by: Marvin Häuser <mhaeuser@posteo.de>
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>
The BIOS Firmware Version in the SMBIOS Type 0 can be fetched from
the fixed PcdFirmwareVersionString or platform specific OemMiscLib.
In fact, the support from OemMiscLib comes into play when the firmware
version may be modified at boot time for extended information.
Therefore, the priority of getting the version from OemMiscLib should
be higher.
In case there is no modification in the OemMiscLib, we have to keep
HII string STR_MISC_BIOS_VERSION empty or 'Not Specified'
to indicate that the firmware version should be fetched from
the PcdFirmwareVersionString.
Signed-off-by: Tinh Nguyen <tinhnguyen@os.amperecomputing.com>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Oliver Smith-Denny <osd@smith-denny.com>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.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>
Expose the protocol introduced in v2.10 that permits the caller to
manage mapping permissions in the page tables.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
In preparation for introducing an implementation of the EFI memory
attributes protocol that is shared between ARM and AArch64, unify the
existing code that converts a page table descriptor into a
EFI_MEMORY_xx bitfield, so it can be called from the generic code.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
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>
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>
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>
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>
The section-to-page attribute conversion takes the shareability and
execute-never attributes into account, whereas the page-to-section
counterpart does not. The result is that GetMemoryRegionPage () -which
takes a section attribute argument (via *RegionAttributes) that is
ostensibly based on the first page in the range, but differs from the
actual page attributes when converted back- may return with a
RegionLength of zero. This is incorrect, and confuses code that scans a
region by calling GetMemoryRegion () in sequence.
So fix the conversion, and ASSERT () on a non-zero region length.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
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>
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>
SetMem arguments 2+3 are in the wrong order, resulting in
the call having no effect because Length is zero.
Fix this by using ZeroMem instead.
Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=4205
Reported-by: Jeremy Boone <jeremy.boone@nccgroup.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
As per the SCMI specification, section CLOCK_DESCRIBE_RATES mentions
that the value of num_rates_flags[11:0] in the response must be 3 if
the return format is the triplet. Due to the buggy firmware, this was
not noticed for long time. The firmware is now fixed resulting in
ClockDescribeRates() to fail with "Buffer Too Small" error as the
RequiredArraySize gets miscalculated as 72 instead of 24.
Fix the issue by reusing the logic for both the return format which
must work if num_rates_flags has correct value as expected from the
specification.
Cc: Girish Pathak <girish.pathak@arm.com>
Cc: Jeff Brasen <jbrasen@nvidia.com>
Reviewed-by: Pierre Gondois <pierre.gondois@arm.com>
Tested-by: Pierre Gondois <pierre.gondois@arm.com>
Reported-by: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Tested-by: Sami Mujawar <sami.mujawar@arm.com>
The RealView Debugger is related to RVCT, which is no longer supported.
Given that, remove RvdPeCoffExtraActionLib and code from
RvdPeCoffExtraActionLib which prints lines for use with the RealView
Debugger.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Acked-by: Bob Feng <bob.c.feng@intel.com>
Add support for EFI_MP_SERVICES_PROTOCOL during the DXE phase under
AArch64.
PSCI_CPU_ON is called to power on the core, the supplied procedure is
executed and PSCI_CPU_OFF is called to power off the core.
Fixes contributed by Ard Biesheuvel.
Signed-off-by: Rebecca Cran <rebecca@quicinc.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Tested-by: Kun Qin <kun.qin@microsoft.com>
Remove ASSERTs in ArmTrngLibConstructor() that prevent from
booting on DEBUG builds.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4150
GetArmTrngVersion() is used to check the presence of an Arm
Trng. If not found, an ASSERT prevents from booting in DEBUG
builds.
Remove this ASSERT.
Reported-by: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
ArmTrngLib crashes when run in DEBUG mode due to the fact that it passed
the [truncated] GUID value to a DEBUG() print statement instead of a
pointer to the GUID which is what the %g conversion expects.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Bugzilla: 3668 (https://bugzilla.tianocore.org/show_bug.cgi?id=3668)
The Arm True Random Number Generator Firmware, Interface 1.0,
Platform Design Document
(https://developer.arm.com/documentation/den0098/latest/)
defines an interface between an Operating System (OS) executing
at EL1 and Firmware (FW) exposing a conditioned entropy source
that is provided by a TRNG back end.
The conditioned entropy, that is provided by the Arm TRNG interface,
is commonly used to seed deterministic random number generators.
This patch adds an ArmTrngLib library that implements the Arm TRNG
interface.
Acked-by: Leif Lindholm <quic_llindhol@quicinc.com>
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Bugzilla: 3668 (https://bugzilla.tianocore.org/show_bug.cgi?id=3668)
The Arm True Random Number Generator Firmware, Interface 1.0,
Platform Design Document
(https://developer.arm.com/documentation/den0098/latest/)
defines an interface between an Operating System (OS) executing
at EL1 and Firmware (FW) exposing a conditioned entropy source
that is provided by a TRNG back end.
New function IDs have been defined by the specification for
accessing the TRNG services. Therefore, add these definitions
to the Arm standard SMC header.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Add a Null instance of ArmHvcLib in case of library dependencies.
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Sort the section containing HVC/SMC libraries prior to
adding new libraries in this specific section.
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
The ArmMonitorLib provides an abstract interface to issue
an HyperVisor Call (HVC) or System Monitor Call (SMC) depending
on the default conduit.
The PcdMonitorConduitHvc PCD allows to select the default conduit.
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
The ArmMonitorLib provides an abstract interface to issue
an HyperVisor Call (HVC) or System Monitor Call (SMC) depending
on the default conduit.
The PcdMonitorConduitHvc PCD allows to select the default conduit.
The new library relies on the ArmHvcLib and ArmSmcLib libraries.
A Null instance of these libraries can be used for the unused conduit.
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Define a PCD 'PcdMonitorConduitHvc' to select the conduit to use for
monitor calls. PcdMonitorConduitHvc is defined as FALSE by default,
meaning the SMC conduit is enabled as default.
Adding PcdMonitorConduitHvc allows selection of HVC conduit to be used
by virtual firmware implementations.
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
In order to reduce the likelihood that we will need to rely on the logic
that disables and re-enables the MMU for updating a page table entry
safely, expose the XIP version of the helper routine via a HOB and use
it instead of the one that is copied into DRAM. Since the XIP copy is
already clean to the PoC, and will never end up getting unmapped during
a block entry split, we can use it safely without any cache maintenance,
and without running the risk of pulling the rug from under our feet when
updating an entry by going through an invalid mapping.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Leif Lindholm <quic_llindhol@quicinc.com>
Permit the use of this library with the MMU and caches already enabled.
This removes the need for any cache maintenance for coherency, and is
generally better for robustness and performance, especially when running
under virtualization.
Note that this means we have to defer assignment of TTBR0 until the
page tables are ready to be used, and so UpdateRegionMapping() can no
longer read back TTBR0 directly to discover the root table address.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Leif Lindholm <quic_llindhol@quicinc.com>
When updating a page table descriptor in a way that requires break
before make, we temporarily disable the MMU to ensure that we don't
unmap the memory region that the code itself is executing from.
However, this is a condition we can check in a straight-forward manner,
and if the regions are disjoint, we don't have to bother with the MMU
controls, and we can just perform an ordinary break before make.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Drop the optimization that replaces table entries with block entries and
frees the page tables in the subhierarchy that is being replaced. This
rarely occurs in practice anyway, and will require more elaborate TLB
maintenance once we switch to a different approach where we no longer
disable the MMU and nuke the TLB entirely every time we update a
descriptor in a way that requires break-before-make (BBM).
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
In some scenarios, the information of Bios Version, Bios Release
and Embedded Controller Firmware Release are fetched during UEFI
booting. This patch supports updating those fields dynamically
when the PCDs are empty.
Signed-off-by: Nhi Pham <nhi@os.amperecomputing.com>
Reviewed-by: Rebecca Cran <rebecca@quicinc.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
This adds an API to OemMiscLib for fetching the system UUID according to
the platform.
Signed-off-by: Nhi Pham <nhi@os.amperecomputing.com>
Reviewed-by: Rebecca Cran <rebecca@quicinc.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Leif Lindholm <quic_llindhol@quicinc.com>
According to "SMC Calling Convention" specification, section 7.4,
return value of Arm Architecture Calls is stored at first argument of
SMC aguments (ARM_SMC_ARGS). This value can be negative values indicating
error or positive values (including zero) indicating success. Positive
value would contain information of respective Function ID (Section 7.3.4
and 7.4.4).
For that reason, "SMCCC_VERSION" and "SMCCC_ARCH_FEATURES"
Function ID calls read return value from "SmcCallStatus" variable
(Args.Arg0 - first argument of SMC call). But "SMCCC_ARCH_SOC_ID"
Function ID call is reading return value from "SmcParam" variable
(Args.Arg1 - second argument of SMC call) so it leads to unexpected
results of "Jep106Code" and "SocRevision". This patch is to correct it.
Signed-off-by: Nhi Pham <nhi@os.amperecomputing.com>
Reviewed-by: Rebecca Cran <rebecca@quicinc.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Leif Lindholm <quic_llindhol@quicinc.com>
In some scenarios, the processor version may be updated dynamically
from pre-UEFI firmware during booting. But the processor version is
fixed with PCD (PcdProcessorVersion), so it can not be updated it
dynamically. This patch will support setting that value both
statically and dynamically.
Signed-off-by: Nhi Pham <nhi@os.amperecomputing.com>
Reviewed-by: Rebecca Cran <rebecca@quicinc.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Leif Lindholm <quic_llindhol@quicinc.com>
Don't allow spelling errors to break the CI build and inadvertently
reject pull requests - spelling is important but not that important.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Rebecca Cran <rebecca@quicinc.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
In an effort to clean the documentation of the above
package, remove duplicated words, and fix a typo while at it.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.muajwar@arm.com>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
The warm reboot requests from OSPM are mapped to cold reboot. To handle
the warm reboot separately from a cold reboot, update
ArmSmcPsciResetSystemLib and to invoke the PSCI call with parameters
for warm reboot.
Signed-off-by: Pranav Madhu <pranav.madhu@arm.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Hide the Exception implementation details in CpuExcetionHandlerLib and
caller only need to provide buffer
Cc: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Dandan Bi <dandan.bi@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
The ARM_PROCESSOR_TABLE pseudo-ACPI table (which carries a ACPI-table
like header but is published as a EFI config table) is not described in
any relevant spec, and is not known to be relied upon by any OS. Let's
just get rid of it.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Tested-by: Sami Mujawar <sami.mujawar@arm.com>
The issue appears to have been introduced by:
41fb5d46 : ArmPkg/ArmGic: Use the GIC Redistributor instead of GIC Distributor for GICv3
The changes to ArmGicIsInterruptEnabled() introduced the error where the Boolean
result is assigned to Interrupts, but then the bit position check is performed
again (against the computed Boolean result instead of the interrupt mask) during
the return statement.
Fix removes erroneous test and relies on boolean test made at return.
Signed-off-by: Robbie King <robbiek@xsightlabs.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
CpuExceptionHandlerLib has been refactored with following changes:
1. Removed InitializeCpuInterruptHandlers in 2a09527ebc
2. Removed InitializeCpuExceptionHandlersEx and
added InitializeSeparateExceptionStacks in e7abb94d1f
The patch updates ARM version of CpuExceptionHandlerLib to follow
the API changes.
The functionality to ARM platforms should be none.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
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>
We never run any code at EL0, and so it would seem that any access
permissions set for EL0 (via the AP[1] attribute in the page tables) are
irrelevant. We currently set EL0 and EL1 permissions to the same value
arbitrarily.
However, this causes problems on hardware like the Apple M1 running the
MacOS hypervisor framework, which enters EL1 with SCTLR_EL1.SPAN
enabled, causing the Privileged Access Never (PAN) feature to be enabled
on any exception taken to EL1, including the IRQ exceptions that handle
our timer interrupt. When PAN is enabled, EL1 has no access to any
mappings that are also accessible to EL0, causing the firmware to crash
if it attempts to access such a mapping.
Even though it is debatable whether or not SCTLR_EL1.SPAN should be
disabled at entry or whether the firmware should put all UNKNOWN bits in
all system registers in a consistent state (which it should), using EL0
permissions serves no purpose whatsoever so let's fix that regardless.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Tested-by: Alexander Graf <agraf@csgraf.de>
Acked-by: Leif Lindholm <leif@nuviainc.com>
Remove the ClusterId and CoreId fields in the ARM_CORE_INFO structure in
favor of a new Mpidr field. Update code in
ArmPlatformPkg/PrePeiCore/MainMPCore and ArmPlatformPkg/PrePi/MainMPCore.c
to use the new field and call new macros GET_MPIDR_AFF0 and GET_MPIDR_AFF1
instead.
Signed-off-by: Rebecca Cran <rebecca@nuviainc.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3751
Current MM communicate routine from ArmPkg would conduct few checks prior
to proceeding with SMC calls. However, the inspection step is different
from PI specification.
This patch updated MM communicate input argument inspection routine to
assure that "if the `MessageLength` is zero, or too large for the MM
implementation to manage, the MM implementation must update the
`MessageLength` to reflect the size of the `Data` buffer that it can
tolerate", as described by `EFI_MM_COMMUNICATION_PROTOCOL.Communicate()`
section in PI specification.
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Bret Barkelew <Bret.Barkelew@microsoft.com>
Cc: Michael Kubacki <michael.kubacki@microsoft.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Kun Qin <kuqin12@gmail.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Pierre Gondois
Ard Biesheuvel
Michael Kubacki
Sami Mujawar
Jeff Brasen via groups.io
Leif Lindholm
Marcin Juszkiewicz
Oliver Smith-Denny
Taylor Beebe
Kun Qin
Neil Jones
Marvin Häuser
Rebecca Cran
Tinh Nguyen
Gerd Hoffmann
Sudeep Holla
Rebecca Cran
Minh Nguyen
Nhi Pham
Pranav Madhu
Liu, Zhiguang
Robbie King
Ray Ni
Rebecca Cran
Kun Qin