When re-entering EDK2 from a high level OS such as Linux, the GICv3 may
be configured to use split priority drop and deactivate (EOImode == 1),
whereas EDK2's GICv3 driver assumes the default setting of EOImode == 0.
So clear the EOImode bit explicitly when taking control of the GIC.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Now that ArmPkg/Drivers/ArmGic no longer carries a combination of
libraries and DXE drivers, rename the directory to the more idiomatic
ArmPkg/Drivers/ArmGicDxe
Continuous-integration-options: PatchCheck.ignore-multi-package
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Most platforms do not require the flexibility of the ordinary GIC
driver, which supports both GICv2 and GICv3+, and decides at runtime
which version to use.
So expose a GICv3+ version, which only supports a GICv3 or newer.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Most platforms do not require the flexibility of the ordinary GIC
driver, which supports both GICv2 and GICv3+, and decides at runtime
which version to use.
So expose a GICv2 only version, which only supports a GICv2.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Retire all implementations of the ArmGicLib library class, which are no
longer used. For now, retain the library header and library class
declaration: the header file only contains pre-processor defines derived
from the GIC architecture spec, and so this code should probably move
into MdePkg at a later moment.
Continuous-integration-options: PatchCheck.ignore-multi-package
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Move the remaining code in ArmGicLib into ArmGicDxe, its only user, and
drop the dependency on ArmGicLib. Note that ArmGicDxe has an undeclared
dependency on ArmLib, so declare that instead.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
ArmGicArchLib is no longer use so remove all remaining references and
implementations.
Continuous-integration-options: PatchCheck.ignore-multi-package
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
ArmGicArchLib implements a check on the accessibility of the GIC system
register interface, which is a prerequisite for using the GIC in v3
mode. It might be possible to use GICv2 compatibility mode on poorly
configured platforms where the GIC is v3 capable but not accessible, but
in most cases, the GIC is driven in its native mode.
This check is now only carried out in a single place, and there is not
really any reason to keep this in a separate library. Even though
ArmVirtPkg implements its own version, the basic check (and enablement
of the sysreg interface) is still needed.
So move this check into the DXE driver itself, and drop the dependency
on ArmGicArchLib. This allows it to be retired in a subsequent patch.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
ArmGicDxe is the only remaining user of ArmGicLib, and so there is no
need for the abstraction, which is drawn at an arbitrary boundary
anyway. So remove the remaining V2 specific code into the DXE driver.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Move the remaining ArmGicLib code that is shared between the v2 and v3
GIC DXE drivers into ArmGicCommonDxe.c
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Split ArmGicEnableDistributor () into GICv2 and v3 specific versions,
and move them into their single respective callers, so that the original
can be dropped from ArmGicLib altogether.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
ArmGicLib is agnostic about the difference between v2 and v3, but its
APIs are only called from code that is either v2-specific or
v3-specific. That makes the generic interface kind of pointless, and we
can just merge this code into the callers.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
ArmGicEndOfInterrupt () is never used: the v2 and v3 versions of the
driver call respective specific versions directly, and so this API can
be removed.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
ArmGicSendSgiTo () is never used, and is fundamentally tied to multi-CPU
operation which is no longer supported. So drop the implementation.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
The ArmGicLib API exposes ArmGicEnableInterruptInterface () and
ArmGicDisableInterruptInterface (), but only the former is actually
used, and only from the GICv2 driver. So drop the API entirely, and
invoke the v2 version of the underlying interface directly.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Support for GICv2 legacy mode was introduced to accommodate secure world
firmware that was lagging behind in terms of development, and was
running the GIC in v2 mode on the secure side for lack of a GICv3
driver.
As per the GIC architecture, the non-secure world can only run the GIC
in v3 mode if the secure world does so too.
At this point, there is no longer a need to for this fallback: GICv2
support it still needed for platforms such as Raspberry Pi 4 that do not
implement GICv3 at all. But on platforms that do implement it, falling
back to GICv2 is unnecessary.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
StandaloneMmCpu driver is only used for Arm architecture and
StandaloneMmCoreEntryPointLib for Arm has specific implementation with
StandaloneMmCpu driver.
Move StandaloneMmCpu Driver and StandaloneMmCoreEntryPointLib for Arm
to ArmPkg.
Continuous-integration-options: PatchCheck.ignore-multi-package
Signed-off-by: Levi Yun <yeoreum.yun@arm.com>
A compiler warning was detected that 'IntId' could be used uninitialized
in the `else` branch.
Since there are no consumers of this function, it was decided to remove
this function completely.
Signed-off-by: Mike Maslenkin <mike.maslenkin@gmail.com>
Do not use the PCDs as only fixed when there is an option
to use them as dynamic that can be set per SKU.
Signed-off-by: Ashish Singhal <ashishsingha@nvidia.com>
The current implementation operates on 64bit value with implicit value
truncation.
This change updates the involved frequencies to use 64 bit based
operations.
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Kun Qin <kun.qin@microsoft.com>
The current code path supporting `PcdArmGicV3WithV2Legacy` will read 32
bit CPU target and try to program ARM_GIC_ICDIPTR. However, all these
operations are 32bit wide.
This change casts the CpuTarget variable to be UINT32 before calling
MMIO read.
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Kun Qin <kun.qin@microsoft.com>
Makes changes to comply with alerts raised by CodeQL.
The issues here fall into the following category:
1. unsigned-comparison-zero
Signed-off-by: Raymond Diaz <raymonddiaz@microsoft.com>
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>
GetProcessorInfo copies CpuData instead of CpuData.Info. The OUT parameter
ProcessorInfoBuffer is of type EFI_PROCESSOR_INFORMATION, not CPU_AP_DATA.
Fix it to copy the correct member CpuData.Info.
Signed-off-by: Vishal Oliyil Kunnil <quic_vishalo@quicinc.com>
On AARCH64 systems, the GCD is not fully synced with the page table. On
x86 systems, the GCD is synced by adding `EFI_MEMORY_RO`,
`EFI_MEMORY_RP`, and `EFI_MEMORY_XP` to the current capabilities of the
GCD, then the page table attributes are set on the GCD attributes.
However, on AARCH64, the GCD capabilities do not get updated, instead
only the attributes from the page table are masked by the existing GCD
capabilities, which means that any new page table attribute which are
already set are dropped and the GCD does not reflect the state of the
system. This has been seen to cause issues where memory in the page
table that was marked `EFI_MEMORY_XP` had an additional attribute set
using the GCD capabilities, which did not include `EFI_MEMORY_XP`, this
caused the page table to be updated to lose `EFI_MEMORY_XP`, which is a
potential security issue.
The existing behavior on AARCH64 systems is an implementation error, it
assumes one of two things:
- The page table attributes must be a subset of the GCD capabilities
- The GCD does not need to have its capabilities synced to what the page
table attributes are
The first is incorrect as important attributes such as `EFI_MEMORY_XP`
do not get applied to the GCD capabilities by default and therefore must
be synced back. This comment from ArmPkg's CpuDxe driver helps explain:
```c
// The GCD implementation maintains its own copy of the state of memory
// space attributes. GCD needs to know what the initial memory space
// attributes are. The CPU Arch. Protocol does not provide a
// GetMemoryAttributes function for GCD to get this so we must resort to
// calling GCD (as if we were a client) to update its copy of the
// attributes. This is bad architecture and should be replaced with a
// way for GCD to query the CPU Arch. driver of the existing memory
// space attributes instead.
```
However, this comment misses that updating the capabilities is critical
to updating the attributes.
The second is incorrect because significant pieces of core code
reference the GCD attributes instead of the page table attributes. For
example, NonDiscoverablePciDeviceDxe uses the GCD capabilities and
attributes when interacting with a non-discoverable PCI device. When the
GCD is not synced to the page table, we get the errors and security
concerns listed above.
Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com>
This moves the WatchdogDisable() function before the installation of the
gEfiWatchdogTimerArchProtocolGuid protocol. It allows a platform to
promptly carry out platform specific configurations, such as UEFI boot
monitoring, by registering the protocol installation callback.
Signed-off-by: Nhi Pham <nhi@os.amperecomputing.com>
The memory attribute protocol is primarily used by bootloaders
and there are many released bootloaders who use the protocol
incorrectly. It is challenging to debug these situations
because the bootloaders are generally black boxes and we
silently fail on the FW side.
This patch adds logging to some common memory attribute
protocol failures in CpuDxe.
Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.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>
Update GenericWatchdogDxe to disable watchdog interaction after exiting
boot services. Also, move the mEfiExitBootServicesEvent event to the top
of the file with the other static variables.
Signed-off-by: Rebecca Cran <rebecca@os.amperecomputing.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
The calculation of the timer period was broken. Introduce a global
mTimerPeriod so the calculation can be removed. Since mTimerFrequencyHz
is only used in one place, remove the global and make it a local
variable. Do the same with mNumTimerTicks.
Signed-off-by: Rebecca Cran <rebecca@os.amperecomputing.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
The generic watchdog offset register is 48 bits wide, and can be set by
performing two 32-bit writes.
Add support for writing the high 16 bits of the offset register and
update the signature of the WatchdogWriteOffsetRegister function to take
a UINT64 value.
Signed-off-by: Rebecca Cran <rebecca@os.amperecomputing.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
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>
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>
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>
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>
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>
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>