Fix memory leaks by adding missing FreePool calls:
free handle buffers in Stop and initialization routines.
REF:https://uefi.org/sites/default/files/resources/UEFI_Spec_Final_2.11.pdf
Chapter 7.3.15: "Services - Boot Services.LocateHandleBuffer":
It is the caller's responsibility to call the Boot Service.FreePool when
the caller no longer requires the contents of Buffer.
Signed-off-by: Dongyan Qian <qiandongyan@loongson.cn>
Fix memory leaks by adding missing FreePool calls:
cleanup HandleBuffer in GetModuleContextBuffers.
REF: https://uefi.org/sites/default/files/resources/UEFI_Spec_Final_2.11.pdf
Chapter 7.3.15: "Services - Boot Services.LocateHandleBuffer":
It is the caller's responsibility to call the Boot Service.FreePool when
the caller no longer requires the contents of Buffer.
Signed-off-by: Dongyan Qian <qiandongyan@loongson.cn>
Fix memory leaks by adding missing FreePool calls:
free HandleBuffer in HttpUtilitiesDxeUnload.
REF: https://uefi.org/sites/default/files/resources/UEFI_Spec_Final_2.11.pdf
Chapter 7.3.15: "Services - Boot Services.LocateHandleBuffer":
It is the caller's responsibility to call the Boot Service.FreePool when
the caller no longer requires the contents of Buffer.
Signed-off-by: Dongyan Qian <qiandongyan@loongson.cn>
Fix memory leaks by adding missing FreePool calls:
release SpiHcHandles in SpiBusEntry exit path.
REF: https://uefi.org/sites/default/files/resources/UEFI_Spec_Final_2.11.pdf
Chapter 7.3.15: "Services - Boot Services.LocateHandleBuffer":
It is the caller's responsibility to call the Boot Service.FreePool when
the caller no longer requires the contents of Buffer.
Signed-off-by: Dongyan Qian <qiandongyan@loongson.cn>
A split-lock violation in OVMF was discovered due to the
NumApsExecuting field of the MP_CPU_EXCHANGE_INFO
struct (which is used atomically by the AP Reset Vector
assembly code) crossing a cacheline boundary.
Since the MP_CPU_EXCHANGE_INFO struct is unaligned and
the NumApsExecuting field resides after other non-UINTN aligned
fields in the struct (i.e. GdtrProfile/IdtrProfile), the
NumApsExecuting field was allocated at a non-UINTN aligned
address (crossing a cache-line) resulting in the split-lock
violation.
Therefore, align the MP_CPU_EXCHANGE_INFO struct (on a UINTN
boundary) and move the NumApsExecuting field to before the
GdtrProfile/IdtrProfile fields to ensure it is UINTN aligned and
thus resides within a single cacheline avoiding the split-lock.
Do the same for the ApIndex field as it is also used atomically
and thus subject to a split-lock violation.
Cc: Ray Ni <ray.ni@intel.com>
Cc: Jiaxin Wu <jiaxin.wu@intel.com>
Cc: Zhiguang Liu <zhiguang.liu@intel.com>
Cc: Dun Tan <dun.tan@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Star Zeng <star.zeng@intel.com>
Signed-off-by: Aaron Young <aaron.young@oracle.com>
Following the addition of the CM_ARCH_COMMON_PROXIMITY_DOMAIN_INFO
object, rework the Srat Generator.
A Warning message is issued when the Original ProximityDomain
fields are used.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Proximity domains Ids should now be described using the
CM_ARCH_COMMON_PROXIMITY_DOMAIN_INFO object. This adds a level
of indirection: a Token allows to retrieve a
CM_ARCH_COMMON_PROXIMITY_DOMAIN_INFO object, and this object might
either have a hard-coded Id, or rely on the MetadataObjLib to
generate an Id.
Add a GetProximityDomainId () function to the CmObjHelperLib to
factorize this level of abstraction and allow other generators
to re-use the logic.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
The SRAT/HMAT/SLIT tables describe the relations between
ProximityDomain IDs. These proximity domains might represent
memory domains, CPUs, IO, etc.
ProximityDomain IDs are mere IDs. They don't represent anything
and could be generated by the DynamicTablesPkg framework. These
IDs are currently hard-coded by the ConfigurationManager developer.
In order to:
- avoid the developer to keep track of the used ProximityDomain IDs
- have a better internal representation of the relation between
CPUs sharing the same ProximityDomain ID
allow the developer to use Tokens pointing to ProximityDomain
structures.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
The ACPI specification v6.5, sTable 5.158: Processor Structure Flags
states that:
"""
The processor container will have a matching ID
value returned through the _UID method. As not every pro-
cessor hierarchy node structure in PPTT may have a matching
processor container, this flag indicates whether the ACPI pro-
cessor ID points to valid entry. Where a valid entry is possible
the ACPI Processor ID and _UID method are mandatory.
"""
And in:
Table 5.157: Processor Hierarchy Node Structure
"""
If the processor structure rep-
resents a group of associated processors, the structure might
match a processor container in the name space. In that case
this entry will match the value of the _UID method of the as-
sociated processor container. Where there is a match it must
be represented. The flags field, described in Processor Struc-
ture Flags, includes a bit to describe whether the ACPI pro-
cessor ID is valid.
"""
The DynamicTablesPkg currently creates a processor container:
- in the SSDT CPU Topology generator, with the _HID=ACPI0010,
and with a valid _UID
- in the PPTT table
for each CM_ARCH_COMMON_PROC_HIERARCHY_INFO structure.
Thus:
- all the processor containers should have the VALID bit set
if the SSDT CPU Topology table is present.
- if the SSDT CPU Topology table is present, but there is no
PPTT table, then the state of the VALID bit is ignored.
A contrario, an example where the VALID bit should not be set
would be if:
- the SSDT CPU Topology generator is absent
- no processor container is created in the SSDT topology,
i.e. if a flat hierarchy is created.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Some generators share some logic in how they handle CmObj.
In an effort to factorize this code, create a CmObjHelperLib,
aiming to host the common CmObj manipulation logic.
Start by adding a CheckAcpiTablePresent() function, allowing
to check if an ACPI table is in the list of the tables to
install.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
The processor containers might have an associated _UID:
- in their SSDT topology representation
- in their PPTT representation, in the "ACPI Processor ID" field
The _UID of the processor containers is independently generated
by the PPTT and SSDT CPU topology generators. Make use of the newly
created MetadataObjLib to generate a unique and common per-processor
container _UID values.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
The processor containers might have an associated _UID:
- in their SSDT topology representation
- in their PPTT representation, in the "ACPI Processor ID" field
The _UID of the processor containers is independently generated
by the PPTT and SSDT CPU topology generators. Make use of the newly
created MetadataObjLib to generate a unique and common per-processor
container _UID values.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
The newly added MetadataObjLib allows to store information either:
- generated by the DynamictTablesPkg framework
- provided by a ConfigurationManager
- parsed from another source of information
This information might be subject to validation/verification.
This step can only be done once the firmware tables generated
by the DynamictTablesPkg have been generated.
Add a new GetMetadataRoot() callback to the
EDKII_DYNAMIC_TABLE_FACTORY_PROTOCOL. This callback allows
to fetch the Metadata Root, allowing to access all the Metadata
information generated. This Metadata is then validated by the
DynamicTableManagerDxe.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Built on top of the MetadataObjLib, this library aims to
provide functions for each METADATA_ID to:
- Generate new Metadata on the fly: the caller provides
minimal information for a METADATA_ID, and the library
generates the missing information.
- Validate all the Metadata objects for a METADATA_ID.
For instance, _UID must be unique for a _HID/_CID/EISAID.
This patch also adds support for generation/validation of:
- UIDs:
For each EISAID or NameId, UIDs must be unique. The generation
if UIDs is done by a per-EISAID/NameId incrementing counter.
The validation of the Metadata consists in checking for the
uniqueness of the UID per EISAID/NameId.
- ProximityDomains:
Proximity Domain Ids are generated by a counter, starting
from 0.
The validation of the Metadata consists in checking for
the uniqueness of the proximity domain Ids.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
The DynamicTablesPkg allows to generate firmware tables based on
information provided by a user or another source of information
(a device tree for instance).
Some information might be implicitly generated by generators.
For instance, for ACPI tables, AML names or Uids are created by
generators, but not provided by the user or another source of
information.
Some generators might need to cross-reference object/generated data
that was previous generated for an object by another generator.
For instance, there are three different generators creating serial
ports in the AML namespace. These 3 generators must ensure not to use
an Id which was not already created by another generator.
Another example would be a generator needing to reference the AML
path of a serial port. As the AML path is dynamically generated, this
is currently not possible to do.
Add a MetaDataObjLib library to keep track of the meta-data previously
generated for an object.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
ProximityDomain31To8[0] is overwritten by the ProximityDomain
at bits [17-24] and [25-31]. Populate ProximityDomain31To8[1]
and ProximityDomain31To8[2] instead.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
In PRM spec 1.0 section 4.2.2 ACPI Parameter Buffer defines
the signature of ACPI Parameter Data Buffer is 'PRMP'.
This commit adds the signature of ACPI Parameter Data Buffer.
Signed-off-by: Aaron Li <aaron.li@intel.com>
Currently if PcdCpuSmmRestrictedMemoryAccess is a DynamicPcd
it will be accessed during SMM entry causing an error since code
outside of SMM will be called (PcdGetBool).
To fix that PcdCpuSmmRestrictedMemoryAccess is retrieved during
SMM initialization and cached value is used at runtime
Signed-off-by: Sienski Piotr <piotr.sienski@intel.com>
The UEFI spec 2.11 documents EFI_SECURITY_VIOLATION for both
gBS->LoadImage() and gBS->StartImage() as
> [Image was loaded and an ImageHandle was created with a valid
> EFI_LOADED_IMAGE_PROTOCOL. However,] the current platform policy
> specifies that the image should not be started.
Additionally, the spec documents EFI_ACCESS_DENIED for gBS->LoadImage() as
> Image was not loaded because the platform policy prohibits the image
> from being loaded. NULL is returned in ImageHandle.
When image loading/starting fails under the above conditions (according to
the status code being reported), print a hint about Secure Boot. This
should help users diagnose and fix their Secure Boot configuration.
Updates: 77874ceebb
Fixes: https://github.com/tianocore/edk2/issues/10901
Signed-off-by: Laszlo Ersek <laszlo.ersek@posteo.net>
Issue : When user access "Boot Maintenance Manager Menu/Secure Boot
Configuration Menu" with PcdNullPointerDetectionPropertyMask|0x03 and
PcdHeapGuardPageType|0x7FFF protection policy set,
we get X64 Exception Type - 0E(#PF - Page-Fault)
Root cause : When user access "Boot Maintenance Manager Menu/Secure Boot
Configuration Menu", BIOS calls FindQuestionDefaultSetting function and
send EFI VarStore header pointer to AuthFindVariableData function.
When header pointer is NULL, it send NULL pointer to AuthFindVariableData
function and causes the page fault.
Fix : Database.c: In function FindQuestionDefaultSetting, added
NULL pointers check, so that when EFI VarStore header argument is passed
to AuthFindVariableData function, NULL pointer access will not happen.
Test: Cross verified while accessing the "Boot Maintenance Manager Menu/
Secure Boot Configuration Menu" page.
Signed-off-by: DeepakX Singh <deepakx.singh@intel.com>
The latest VS2022 update replaces some code patterns with struct
assignments with `memcpy`. This change convert the code to
explicitly use `CopyMem`.
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
The latest VS2022 update replaces some code patterns with struct
assignments with `memcpy`. This change convert the code to
explicitly use `CopyMem`.
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Adds support for building the C language BaseTools for Windows using
toolchains based on mingw-w64.
Mingw-w64 is a collection of header files, libraries, and tools that
when combined with a compiler enable development of Windows software.
Mingw-w64 is a fork of the original MinGW (Minimalist GNU for Windows).
Most active development on MinGW has ceased and mingw-w64 is now the
actively maintained successor. Mingw-w64 provides a libc implementation
built on top of Microsoft's UCRT (Universal C Runtime) with all
nessesary compiler bindings needed to support the C++11 feature set.
Modern mingw-w64 development appears to have coalesced around MSYS2,
which produces a distributions of both GCC and LLVM/Clang that use
mingw-w64 to target the Windows OS. This MSYS2 Clang distribution has a
UNIX-like directory layout and includes Windows binaries of GNU Make.
Combined with the open source licensing, MSYS2's Clang distribution is a
highly attractive choice as an alternative Windows SDK for open source
projects such as TianoCore.
If one wishes to use EDK II to build UEFI firmware on the Windows
platform, then the C BaseTools need to be compiled as Windows
applications. This includes the PcdValueInit.exe program, which needs
to be recompiled every time a firmware build is run in order to
regenerate the initial values for structured PCDs. Currently, BaseTools
only supports the Visual C++ toolchain on the Windows platform. The
following new features have been added to enable usage of the toolchains
derived from mingw-w64:
- Fixes to the BaseTools C source code to support the use of a
GCC-style compiler on the Windows OS.
- The GNU Make-style Makefiles for the C BaseTools have been modified
to support Windows. Both GCC + mingw-w64 and Clang + mingw-w64 have
been tested and confirmed to build a working BaseTools.
- BaseTools now supports generating GNU Make-style Makefiles on the
Windows platform for the purpose of building firmware.
- edksetup.bat has been modified to optionally build BaseTools via
mingw-w64. There is no impact to the existing support for Visual C++
and Visual C++ remains the default toolchain.
Usage Instructions:
For the vast majority of users, the only system setup change nessesary
to use a mingw-w64 toolchain is to set the BASETOOLS_MINGW_PATH to the
directory containing the desired mingw-w64 based toolchain.
A new command line argument has been added to edksetup.bat: Mingw-w64
If this command line argument is set, then the script will set the
BASETOOLS_MINGW_BUILD environment variable. The user can also opt to set
this environment variable manually before running edksetup.bat
If BASETOOLS_MINGW_BUILD is defined, then the BASETOOLS_MINGW_PATH
environment variable must point to the directory containing the
mingw-w64 toolchain.
If CLANG_BIN is not defined and %BASETOOLS_MINGW_PATH%\bin\clang.exe
exists, then edksetup.bat will set CLANG_BIN=%BASETOOLS_MINGW_PATH%\bin\
This removes the requirement to configure the CLANG_BIN environment
variable manually in order to run a CLANGPDB or CLANGDWARF build if one
has the MSYS2 Clang distribution installed. If one wishes to use a
different copy of Clang (for example official LLVM binaries) to build
firmware and only use the MSYS2 Clang to build BaseTools, then one can
continue to set the CLANG_BIN environment variable, same as before. I
have tested the MSYS2 Clang distribution against the official LLVM
distribution and can confirm that if the compiler version is the same
the emitted machine code is identical between the two. Interestingly,
the MSYS2 Clang distribution emits the path to the PDB file using "/" as
the path seperator instead of "\". That appears to be the only
difference in output. Therefore, using the MSYS2 Clang distribution to
compile firmware seems a reasonable choice.
If CLANG_HOST_BIN is not defined and BASETOOLS_MINGW_BUILD is defined
and %BASETOOLS_MINGW_PATH%\bin\mingw32-make.exe exists, then
edksetup.bat will add %BASETOOLS_MINGW_PATH%\bin\ to the PATH and set
CLANG_HOST_BIN=mingw32-
This enable usage of the GNU Make included in the mingw-w64 toolchain
to build firmware in addition to BaseTools. if BASETOOLS_MINGW_BUILD is
not defined, edksetup.bat will continue to set CLANG_HOST_BIN=n, which
uses nmake to build firmware. This behavior can be overridden by
manually setting the value of CLANG_HOST_BIN before executing
edksetup.bat if one wishes to use a specific Make utility for the
CLANGPDB/CLANGDWARF toolchains.
References:
- https://www.mingw-w64.org/
- https://www.msys2.org/
Co-authored-by: Sandesh Jain <sandesh.jain@intel.com>
Signed-off-by: Nate DeSimone <nathaniel.l.desimone@intel.com>
Fixes a BaseTools Bin directory path detection bug in the the BaseTools
Unit Tests. The script incorrectly assumes that sys.platform
will be win64 on a 64-bit Python interperter.
The "win64" platform string has not been used for 64-bit Python
interperters since May 10, 2000:
https://github.com/python/cpython/commit/da5cc82d
Moreover, this patch was merged before the Python 2.0 release, so there
never has been a released Python interperter that used the "win64"
string.
Signed-off-by: Nate DeSimone <nathaniel.l.desimone@intel.com>
PatchCheck error messages can be improved by adding the line number.
The line itself may consist of only whitespace for some errors.
Adding the line number can help better locate the error source.
Signed-off-by: Gary Beihl <garybeihl@microsoft.com>
To get a SPI_MAX_INTID, interrupt controller type Register
should be masked with ARM_GIC_ICDICTR_GET_SPI_RANGE.
However, since ARM_GIC_ICDICTR_SPI_RANGE_TO_MAX_INTID macro
uses ARM_GIC_ICDICTR_GET_EXT_SPI_RANGE mask,
it returns wrong SPI_MAX_INITID.
This makes a failure of loading GenericWatchDog in FVP RevC model.
Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
Fixes: d6d2f68e38 ("ArmPkg/Drivers/ArmGicDxe: ...")
As new interfaces are made available to support UUID-GUID conversion,
this change is made to leverage new interfaces and remove the locally
duplicated code.
Signed-off-by: Kun Qin <kun.qin@microsoft.com>
This change moves the existing ConvertEfiGuidToUuid function to public
interface to support newly defined functions prototypes.
This change also adds the `ArmConvertUuidToEfiGuid` function
implementation, which is an inverse of the original conversion.
Signed-off-by: Kun Qin <kun.qin@microsoft.com>
With interactions between Standalone MM partitions and normal UEFI
environment, there is constant need to convert UUID to GUID and back.
This change added 2 new interfaces to BaseLib that support such usage.
Signed-off-by: Kun Qin <kun.qin@microsoft.com>
This is needed in a MM_CORE_STANDALONE module. Since this null
instance is so simple, remove individual module types to allow
it be integrated more easily.
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
- Updated the PciGetBusRange function signature to use IN OUT for
the Descriptors parameter.
- Introduced a new DescriptorsBuffer variable in PciLib.c to
temporarily hold descriptor data.
- Clean up DescriptorsBuffer and set Descriptors to NULL after use.
Co-authored-by: Michael Kubacki <michael.kubacki@microsoft.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
KEYBOARD_TIMER_INTERVAL is used as TriggerTime parameter of
gBS->SetTimer() function. TriggerTime parameter represents the number of
100ns units, so number 500000 indicates 0.05s.
Signed-off-by: Gao Qihang <gaoqihang@loongson.cn>
Original logic skips to call MmDispatcher() when number of FV HOBs exceeds
the max supported FVs even for the already-discovered FVs.
Original logic skips to call MmDispatcher() and even skips to process other
FVs when insufficient MM memory for shadowing a FV.
For both cases, replace "return" with "continue" to try best to dispatch
more FVs.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Refine debug output for better troubleshooting:
1. Consolidate FV address and size into one log message
2. Add function name to error messages for better traceability
3. Use AllocateCopyPool() instead of separate AllocatePool() and CopyMem()
Signed-off-by: Ray Ni <ray.ni@intel.com>
Previously, MmDispatchFvs could enter an infinite loop if a Firmware Volume
HOB with zero length was encountered, because GetNextHob() was called with
the same FvHob pointer repeatedly. This patch fixes the issue by passing
GET_NEXT_HOB(FvHob) to GetNextHob(), ensuring the loop advances to the next
HOB and preventing hangs.
Signed-off-by: Ray Ni <ray.ni@intel.com>
This commit enables extended SPI support for GicV3. GicV3 must decide,
based on the source intid, whether to access the SPI-range registers,
PPI-range registers in the redistributor, or the extended SPI-range
registers.
The protocol interfaces must also support registering an interrupt
handler with an extended SPI intid. To save ~24KB of memory, handler
allocation and access is delegated to GicV2 and GicV3. GicV2 retains the
existing handler mapping scheme using intids literally. GicV3 remaps
extended SPI intids to be immediately after the highest SPI intids.
Tested on qemu with the BSA test suite.
Signed-off-by: Nick Graves <nicholasgraves@google.com>
PrePiLib.h is missing the header file that defines
the structures used in the file.
For example:
- EFI_PEI_FV_HANDLE
- EFI_PEI_FILE_HANDLE
Signed-off-by: Doug Flick <dougflick@microsoft.com>
With all in-tree users migrated, finally delete this.
Any out-of-tree users need to migrate to MdePkg BaseFdtLib.
Signed-off-by: Leif Lindholm <leif.lindholm@oss.qualcomm.com>
ArmStandaloneMmCoreEntryPoint makes use of GetNextHob
which comes from HobLib. The inf does not specify
HobLib has one of its library classes. Specify
HobLib in the LibraryClasses section of the
inf.
Signed-off-by: Aaron Pop <aaronpop@microsoft.com>
When calling to initialize the PL011 Uart, Rx buffer is
not cleared. In a 16550 uart device, during initialization,
the 16550's Fifo control registers would be used to clear
the Rx buffer, but no such register exists on PL011.
Modify the PL011 SerialPortInitialize function
to clear anything that was in the Rx buffer
after initialization is completed. This will prevent
any stale data from being interpreted as valid data.
Signed-off-by: Aaron Pop <aaronpop@microsoft.com>
Commit e25331fc45
("MdePkg,UefiPayloadPkg: clean up BaseFdtLib API confusion"),
missed out aligning the wrapper for fdt_node_offset_by_property_value
between heade and implementation.
Fix this by updating the header to declare FdtNodeOffsetByPropValue
instead of FdtNodeOffsetByPropertyValue.
Signed-off-by: Leif Lindholm <leif.lindholm@oss.qualcomm.com>
When building with gcc 15.1, building RegularExpressionDxe fails
because it can't find the type ptrdiff_t. Therefore, add a typedef
for it in OniguramaUefiPort.h.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
