summaryrefslogtreecommitdiffstats
path: root/ArmPkg
Commit message (Collapse)AuthorAgeFilesLines
* ArmPkg/ArmMmuLib: Use function pointer typeMichael Kubacki2023-11-285-13/+33
| | | | | | | | | | | | | | | | | | | 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>
* ArmPkg/ArmLib: Add ArmHasEte () helper functionSami Mujawar2023-10-303-1/+30
| | | | | | | | | | | | | 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>
* ArmPkg/ArmLib: Add ArmHasTrbe () helper functionSami Mujawar2023-10-303-0/+31
| | | | | | | | | | | | | 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>
* ArmPkg/ArmPsciMpServices: Add EFI_NOT_READY returnJeff Brasen via groups.io2023-10-181-1/+3
| | | | | | | | | | | 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>
* ArmPkg/ArmLib: Add ArmHasVhe () helper functionLeif Lindholm2023-09-203-0/+36
| | | | | | | | | | | | | 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>
* ArmPkg: add EL2 virtual timer interrupt PcdLeif Lindholm2023-09-191-0/+1
| | | | | | | | | | | | | | 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>
* ArmPkg/ArmMmuLib: Drop buggy secure memory type checkArd Biesheuvel2023-09-122-4/+0
| | | | | | | | | | | | | | | Jake reports that the IS_ARM_MEMORY_REGION_ATTRIBUTES_SECURE() macro is no longer accurate since commit 852227a9d52e3cb9 ("ArmPkg/Mmu: Remove handling of NONSECURE memory regions"). Fortunately, it only affects the NS bit in level 1 short descriptors, which is ignored when executing in non-secure mode. And given that running UEFI in the secure world is not a use case we aim to support, let's just drop this logic altogether. Reported-by: Jake Garver <jake@nvidia.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
* Revert "ArmPkg: add ArmCpuInfo EFI application"Marcin Juszkiewicz2023-09-053-2462/+0
| | | | | | | | | I am moving this command outside of EDK2. This reverts commit 2c2cb235289642775a7c4e6eaeffa6d3828d279c. Signed-off-by: Marcin Juszkiewicz <marcin.juszkiewicz@linaro.org> Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
* ArmPkg/SmbiosMiscDxe: use UINT64 for BiosPhysicalSizeLeif Lindholm2023-08-301-1/+1
| | | | | | | | | | | | | | | | 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>
* ArmPkg: DefaultExceptionHandlerLib: Do Not Allocate MemoryOliver Smith-Denny2023-08-032-15/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* ArmPkg: Add Function Headers to MMU LogicTaylor Beebe2023-07-032-9/+169
| | | | | | | | | 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>
* ArmPkg: Fix Unsafe ASSERTs in MMU LogicTaylor Beebe2023-07-032-12/+45
| | | | | | | | | | 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>
* ArmPkg: Update GetMemoryRegion() to Handle No mappingTaylor Beebe2023-07-032-35/+60
| | | | | | | | | | | | | | | | | | | 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>
* ArmPkg: Apply Uncrustify to Non-Compliant FilesTaylor Beebe2023-07-032-7/+7
| | | | | | | | | 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>
* ArmPkg: MmCommunicationPei: Introduce MM communicate in PEIKun Qin2023-06-283-0/+263
| | | | | | | | | | | | | | | | | | | 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>
* ArmPkg/OpteeLib: Map shared communication buffer non-executableArd Biesheuvel2023-06-271-1/+6
| | | | | | | | | | 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>
* ArmPkg: Drop individual memory permission helpersArd Biesheuvel2023-06-274-304/+4
| | | | | | | | | | Now that we have a sane API to set and clear memory permissions that works the same on ARM and AArch64, we no longer have a need for the individual set/clear no-access/read-only/no-exec helpers so let's drop them. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
* ArmPkg/CpuDxe: Simplify memory attributes protocol implementationArd Biesheuvel2023-06-261-48/+2
| | | | | | | | | | | 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>
* ArmPkg/CpuPei: Implement the memory attributes PPIArd Biesheuvel2023-06-262-0/+80
| | | | | | | | | | | 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>
* ArmPkg/ArmMmuLib: Extend API to manage memory permissions betterArd Biesheuvel2023-06-265-17/+167
| | | | | | | | | | | | | | | | | | | | | | | | | | Currently, ArmSetMemoryAttributes () takes a combination of EFI_MEMORY_xx constants describing the memory type and permission attributes that should be set on a region of memory. In cases where the memory type is omitted, we assume that the memory permissions being set are final, and that existing memory permissions can be discarded. This is problematic, because we aim to map memory non-executable (EFI_MEMORY_XP) by default, and only relax this requirement for code regions that are mapped read-only (EFI_MEMORY_RO). Currently, setting one permission clears the other, and so code managing these permissions has to be aware of the existing permissions in order to be able to preserve them, and this is not always tractable (e.g., the UEFI memory attribute protocol implements an abstraction that promises to preserve memory permissions that it is not operating on explicitly). So let's add an AttributeMask parameter to ArmSetMemoryAttributes(), which is permitted to be non-zero if no memory type is being provided, in which case only memory permission attributes covered in the mask will be affected by the update. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Oliver Smith-Denny <osde@linux.microsoft.com> Reviewed-by: Michael Kubacki <michael.kubacki@microsoft.com>
* ArmPkg: add SMC defines for SiP service callsMarcin Juszkiewicz2023-06-021-0/+9
| | | | | | | 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>
* ArmPkg: Enable AuditMode for Uncrustify CI checksArd Biesheuvel2023-06-021-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | 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 429309e0c6b74792) - it forces indentation-only changes to code in the vicinity of actual changes, making the code history more bloated than necessary (see commit 7f198321eec0f520373 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>
* ArmPkg: Fix ArmGicAcknowledgeInterrupt () for GICv3Sami Mujawar2023-06-011-6/+10
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* ArmPkg: Adjust variable type and cast for RegShift & RegOffsetSami Mujawar2023-06-012-15/+15
| | | | | | | | | | | 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>
* ArmPkg: Prevent SgiId from setting RES0 bits of GICD_SGIRSami Mujawar2023-06-011-1/+3
| | | | | | | | | | 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>
* ArmPkg: Remove unused function declarationsSami Mujawar2023-06-011-14/+0
| | | | | | | The IrqInterruptHandler () and ExitBootServicesEvent () function declarations were unused. Therefore, remove these declarations. Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
* ArmPkg: Typecast IntID to UINT32 in ArmGicV2EndOfInterruptSami Mujawar2023-06-011-2/+4
| | | | | | | | | | | | | 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>
* ArmPkg: Make variables used for GicInterrupt UINTNSami Mujawar2023-06-012-6/+6
| | | | | | | | | | | | 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>
* ArmPkg: Fix return type for ArmGicGetInterfaceIdentificationSami Mujawar2023-06-012-2/+2
| | | | | | | | | 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>
* ArmPkg: Fix Non-Boolean comparison in ArmGicEnableDistributorSami Mujawar2023-06-011-1/+3
| | | | | | | | | | | 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>
* ArmPkg: Fix ArmGicSendSgiTo() parametersSami Mujawar2023-06-012-6/+6
| | | | | | | | | | | | | | 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>
* ArmPkg: Fix data type used for GicInterruptInterfaceBaseSami Mujawar2023-06-014-16/+24
| | | | | | | | | | | | | | | 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>
* ArmPkg: Fix data type used for GicDistributorBaseSami Mujawar2023-06-016-25/+27
| | | | | | | | | | | | | | 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>
* ArmPkg: Fix GicV2 BaseAddress typesNeil Jones2023-06-011-2/+2
| | | | | | | | | 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>
* ArmPkg/CpuDxe: Perform preliminary NX remap of free memoryArd Biesheuvel2023-05-293-0/+93
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* ArmPkg: Configure PcdEmuVariableNvModeEnable as a dynamic PCDSami Mujawar2023-05-291-1/+1
| | | | | | | | | | | | | | | | 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>
* ArmPkg/CpuDxe AARCH64: Report Memory Protection Attributes To GCDOliver Smith-Denny2023-05-291-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* ArmPkg/ArmMmuLib AARCH64: Add missing ISB after page table updateArd Biesheuvel2023-05-231-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* ArmPkg/PlatformBootManagerLib: Add path to boot UEFI Shell over UiAppPierre Gondois2023-05-043-3/+82
| | | | | | | | | | | | | | | | | | 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>
* ArmPkg: add ArmCpuInfo EFI applicationMarcin Juszkiewicz2023-04-213-0/+2462
| | | | | | | 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>
* ArmLib: add functions to read system registersMarcin Juszkiewicz2023-04-212-9/+99
| | | | | | | | 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>
* ArmPkg: older assemblers may lack ID_AA64ISAR2_EL1Marcin Juszkiewicz2023-04-201-0/+4
| | | | | | | | | | | 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>
* ArmPkg/ArmMmuLib: Fix ArmReplaceLiveTranslationEntry() alignmentMarvin Häuser2023-04-201-6/+8
| | | | | | | | | | | | | | | | | | 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>
* ArmPkg/AsmMacroIoLibV8: Introduce ASM_FUNC_ALIGN()Marvin Häuser2023-04-201-0/+11
| | | | | | | | | | | | | | | | 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>
* ArmPkg: Update code to be more C11 compliant by using __func__Rebecca Cran2023-04-1013-34/+34
| | | | | | | | | | | | __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>
* ArmPkg, BaseTools AARCH64: Add BTI ELF note to .hii objectsArd Biesheuvel2023-03-301-0/+0
| | | | | | | | | | | | | | | | 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>
* ArmPkg/GccLto AARCH64: Add BTI note to LTO helper libraryArd Biesheuvel2023-03-301-0/+0
| | | | | | | | | | | | | 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>
* ArmPkg: Emit BTI opcodes when BTI codegen is enabledArd Biesheuvel2023-03-303-6/+6
| | | | | | | | | | | | | | | | 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>
* ArmPkg/SmbiosMiscDxe: Adjust the priority of getting firmware versionTinh Nguyen2023-03-281-24/+38
| | | | | | | | | | | | | | | | | | | 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>
* ArmPkg/ArmMmuLib: Introduce region types for RO/XP WB cached memoryArd Biesheuvel2023-03-163-6/+47
| | | | | | | | | | | | | | | | 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>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-25 05:04:25 +0000