Now that the X64 StandaloneMmCoreEntryPoint has been moved to
MdePkg, it can be removed from StandaloneMmPkg and consumed
from MdePpkg.
Signed-off-by: Oliver Smith-Denny <osde@microsoft.com>
Moves StandaloneMmCoreEntryPoint for X64 to MdePkg to live with
the other entry point libs. It does not move the ARM64 version,
as this was just moved to ArmPkg due to its heavy coupling with
ArmPkg code. This will need to be revisited when dynamic stack
cookie support is added to ARM64 StMM.
This commit just adds the library in MdePkg, a separate commit
will remove it from StandaloneMmPkg to make it easier to consume.
Signed-off-by: Oliver Smith-Denny <osde@microsoft.com>
StackCheckLib defines the interface between a compiler
and the stack checking code. It is being converted from
a NULL library class to an actual library class to make
it easier to use for a platform and be easier to define
the expected interface with a compiler, so if there is
a compiler change it can be tracked and caught.
Signed-off-by: Oliver Smith-Denny <osde@microsoft.com>
RNDR is a standard register defined in the ARM ARM for
AARCH64. Move the definition from BaseRngLib to AArch64.h.
Furthermore, move the inclusion of this register definition
to the ARM specific header file.
Signed-off-by: Oliver Smith-Denny <osde@microsoft.com>
REF:https://github.com/tianocore/edk2/issues/10529
The `RngPei` PEIM can be used if RNG should be provided over a
dynamic binary interface to other PEIMs on a platform.
Tested with:
- SecurityPkg CI
- Verify RNG linked with RngLib is executed as expected
- Verify random numbers are generated successfully with a valid
RngLib
Integration instructions:
Use the `RngPei` module if a platform needs to produce
`gEfiRngPpiGuid`.
The platform should usually link a different `RngLib` instance to
`RngPei` than other PEIMs that may use the RNG PPI produced since
`RngPei` is responsible for producing the PPI.
For example, a `RngLib` instance that uses the rdrand instruction
may be linked against `RngPei` and a `RngLib` instance that uses
the RNG PPI may be linked against other PEIMs.
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
REF:https://github.com/tianocore/edk2/issues/10529
Adds a new PEI library instance for RngLib that uses the RNG services
provided by the RNG PPI.
This library instance will add a DEPEX on gEfiRngPpiGuid on modules
it links against. It can be used to allow PEIMs to get RNG support
over a dynamic interface.
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
REF:https://github.com/tianocore/edk2/issues/10529
Adds a new PPI that serves the same purpose as EFI_RNG_PROTOCOL in
DXE. This PPI can be produced by a PEIM to provide a dynamic interface
to RNG services in PEI.
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Move the structure definition to a common location that can be shared
with the RNG PPI. Move the algorithms to a common header that can be
referenced independent of the protocol.
Include the algorithm header in the interface header since the
algorithms are directly used in the interface and for compatibility
with existing code.
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
We've migrated bugzilla bugs to github issues, so update the references
to specific bugs called out in the top-level readme.
Also delete the references to BZ2661 and BZ2668 which are both *closed*:
https://github.com/tianocore/edk2/issues/8453https://github.com/tianocore/edk2/issues/8458
And drop bugzilla.tianocore.org from "references".
The server is no longer in use, and the certificate has expired,
so stop telling people to go there.
Signed-off-by: Leif Lindholm <leif.lindholm@oss.qualcomm.com>
Update BZ links to corresponding GitHub issues links now that the
BZ -> GitHub issue migration is complete.
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
By default, Doxygen tries to nicely format all text within doc blocks.
Unfortunately this mangles ASCII art: add @verbatim statements
to EdkiiSystemFmpCapsule.h to cause Doxygen to display the text as
provided.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
With the latest GccBase.lds combining with CLANG build, there is no
need to enforce 4KB alignment of in UPL CLANGDWARF build.
This reverts commit b3bfb8f22d.
Signed-off-by: Chasel Chiu <chasel.chiu@intel.com>
This adds #defines and struct typedefs for the various structure
types in the CXL Early Discovery Table (CEDT).
Signed-off-by: Yuquan Wang <wangyuquan1236@phytium.com.cn>
If command line options are moved into a response file
of a GCC family build, then the file path separators are
converted from '\' to '/'. However, this can corrupt
command line options that are quoted strings.
Update GenMake to no convert '\' to '/' in quoted strings.
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
The linker option 'no-warn-rwx-segments' breaks both the LLVM linker and
versions of the binutils ld.bfd linker prior to 2.39.
Now that the ELF image is made up of separate R-X and RW- segments, this
warning is no longer emitted and so there is no longer a need to
suppress it either.
While at it, move GCC_DLINK_FLAGS_COMMON (which is not common but only
used by Ia32 and X64) into its only user so it can be dropped.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
To prevent the ELF linkers from complaining about emitted ELF segments
that require both writable and executable permissions, define two
separate R-X and RW- ELF segments, and emit the output sections
explicitly into those segments as appropriate.
Note that this has no bearing on the PE image, and using a single RW-
segment would probably be fine too.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
The original reason for creating a separate version of the ELF linker
script for Clang was the difference between COMMONPAGESIZE and
MAXPAGESIZE, which can we provided on the command line to the respective
linkers (ld.bfd versus lld). That difference no longer exists, and both
use COMMONPAGE_SIZE. So there is no longer a need to maintain a fork,
which has already been going out of sync with the original for no good
reason.
So merge the two and call it GccBase.lds
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
The GccBase.lds and ClangBase.lds ELF linker scripts have been laid out
very carefully to ensure that the memory mappings of .text and .data are
such that they can be preserved in the PE/COFF memory image. This
removes the need to update any place-relative ELF relocations when
generating the PE/COFF image, making its job much easier, and
potentially allowing it to disregard static ELF relocations altogether,
and rely solely on dynamic ELF relocations.
Adding an arbitrary .entry section before .text breaks those
assumptions, so instead of emitting it as a separate section, move its
payload to the start of .text.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Original ELF segment/section syncup process having layout assumption
which has caused build failure when layout changing.
New process will parse both existing segments and sections firstly to
support different layout.
Signed-off-by: Chasel Chiu <chasel.chiu@intel.com>
The command line option --no-warn-rwx-segments was added to the linker
command line for all GCC family builds on ARM and AARCH64, including
CLANGDWARF and GCC49 and older, none of which are intended for use with
linkers that actually understand this option.
So instead, move it to the GCC5 DLINK FLAGS definitions for ARM and
AARCH64 (which are inherited by the versionless GCC which is intended to
replace GCC5 at some point).
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
This reverts commit 43233ff9f8.
The TPM code (and possibly others too) must be fixed to also
map their MMIO ranges before we can do this cleanup.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
When running the verbose builds on arm for development and testing
it is quite convenient to use virtio serial to interact with the
system because console and logging are separated then. Except that
the virtio serial driver spams the debug log in that case. Set the
debug level for the driver to zero to avoid that.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
The prehistoric code base doesn't build with ISO C23. Set the C
standard to C11 (for both clang and gcc) so it continues to build with
gcc 15 (which uses C23 by default).
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
gcc 15 switched to use the new ISO C23 standard by default.
'bool', 'true' and 'false' are keywords in C23, so do not
try to define them.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
UEFI 2.11 has been published on https://uefi.org/specifications
It defines SM3 crypto algorithm GUID and structure.
Signed-off-by: Liming Gao <gaoliming@byosoft.com.cn>
Since the CI is now running on Fedora 40, let's also switch over
VSCode Devcontainer to use the same.
Signed-off-by: Oliver Steffen <osteffen@redhat.com>
These archs are not supported by ArmPkg so we can save agent
resources by not attempting to schedule their CodeQL build.
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
ArmDisassemblerLib is used to pretty print the instruction that
triggered an unhandled exception, but it was never implemented for
AARCH64, and according to the existing file comment, Thumb2 support
(which is used predominantly when building EDK2 for 32-bit ARM due to
its smaller size) is incomplete.
The DEBUG diagnostics that are produced on an unhandled exception are
generally sufficient to dump the entire executable that triggered it,
and so this disassembly is of limited value, especially because it
doesn't work on AARCH64.
So let's start getting rid of it, by dropping references to it in code
and in the various .INF and .DSC files. Once out-of-tree platforms have
been allowed to catch up, we can remove the library implementation and
its class definition entirely.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
There were several bugs in the vector table relocation code which means
it can't really have been used by anyone on AArch64 in the last decade or
so. So delete the support code from the library, as well as the
ArmRelocateExceptionLib.inf file.
This gets rid of PcdDebuggerExceptionSupport (including a duff reference
in CpuDxe), PcdCpuVectorBaseAddress and PcdRelocateVectorTable.
Signed-off-by: Leif Lindholm <leif.lindholm@oss.qualcomm.com>
Currently, the ArmVirtQemu startup code maps a 128 MiB of MMIO space, as
it knows that the UART, GIC and RTC live there. Now that the GIC driver
maps its MMIO registers itself, there is no need for this region to
cover its MMIO space. And there are other regions here that don't need
to be mapped by default: the only ones that need to be mapped are the
UARTS, the RTC, the fw_cfg MMIO interface and the virtio-mmio regions,
all of which live in a 32 MiB window starting at address 0x900_0000.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
The GIC driver itself has intimate knowledge of the hardware, and so it
is the best suited to create the mappings of the MMIO control regions,
in case they have not been mapped yet by the platform code.
So call in the the CPU arch protocol to map the CPU interface,
distributor and redistributor regions as they are discovered by the GIC
driver startup code.
Note that creating these mappings has no effect if the regions in
question have already been mapped with the correct attributes.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
The GIC distributor and redistributor addresses that are passed into the
interrupt enable and disable routines are always the same, so just use
the global variables directly.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
The GIC DXE driver only runs on the boot CPU, and so there is really no
point in iterating over all the redistributor frames every time an
interrupt is enabled, disabled or its state tested. Instead, do this
only at load time.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Instead of relying on a protocol notification event to register the core IRQ
interrupt handler with CPU arch protocol once it becomes available, use
a DEPEX to ensure that the GIC driver is not dispatched at all until the
CPU arch protocol has turned up.
This will allow the GIC driver to use other CPU arch protocol methods,
such as the ones needed to map the GIC MMIO regions at driver startup.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Currently, ArmPkg's CpuDxe DEPEXes on the hardware interrupt protocol,
to ensure that it is not dispatched before the GIC driver. This way, the
CpuDxe driver is guaranteed not to enable interrupts on the CPU side
before the GIC driver has had the opportunity to configure the
interrupts on the distribution side.
However, this prevents the GIC driver from using any of the CPU arch
protocol interfaces, such as mapping memory, which it may need to do on
platforms where the GIC MMIO regions are not mapped yet when the driver
is started.
So instead, use a protocol notification on the hardware interrupt
protocol, which is installed by the GIC driver (as well as other
existing interrupt controller drivers for platforms that do not
implement a GIC) after it starts up and deasserts and disables all
incoming interrupts. Manipulate the interrupt state as usual only after
this notification has been received. Before that, keep track of the
caller's intent regarding the interrupt enabled state in a shadow
variable, but do not actually enable interrupt delivery to the CPU just
yet.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
There is some fossilized code in the CpuDxe driver startup code that
permits a vector table to be inherited from the PEI stage, but this code
is essentially dead on ARM platforms, given that the VectorInfo argument
passed to InitializeCpuExceptionHandlers() is ignored, and no code
appears to exist that would result in the gEfiVectorHandoffTableGuid
configuration table ever being populated.
Also, due to prior refactoring, the code that disables and re-enables
IRQs and FIQs is completely pointless, and can simply be removed. That,
in turn, allows the CPU arch protocol parameter to be dropped from the
prototype of InitializeExceptions().
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Use static linkage for variables and routines that are not referenced
from other objects. This is generally preferred, because it gives the
compiler more freedom for optimization.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Failure to install the CPU arch protocol is a fatal error, so treat it
as such, rather than ignore it, even though we won't get very far if
this driver fails to dispatch - at least, we will get an error in a
DEBUG build rather than a mysterious failure due to unsatisfied DEPEXes.
Failure to install the idle loop event handler is not a fatal error, and
it should not cause the driver to exit with an error, as this will
unload the driver and keep the installed CPU arch protocol pointer
dangling. So keep the ASSERT() on the return value, but return
EFI_SUCCESS once we're past the point where the CPU arch protocol has
been installed.
Since the protocol is never uninstalled, make the CPU handle function
local, as there is no point in keeping its value around.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Oliver Smith-Denny
Leif Lindholm
Chasel Chiu
Michael Kubacki
Aaron Li
Rebecca Cran
Dionna Glaze
Yuquan Wang
Michael D Kinney
Ard Biesheuvel
INDIA\sachinganesh
Gerd Hoffmann
Andrei Warkentin
Liming Gao
Oliver Steffen