Tianocore/edk2.git/BaseTools/Source/C, branch edk2_master

BaseTools/Source/C/Makefiles: Detect cycle in pids

2026-01-06T06:27:41+00:00

Update _get_win32_parent_processes() to detect a cycle in parent process ids that can cause _get_win32_parent_processes() to never return. If a pid cycle is detected, then return the list of parent process ids detected up to the point the cycle is detected. GitHub Actions builds using windows-2025 can reproduce this issue once in a while. It shows up as job that runs until a timeout. If the job is canceled, the logs show a python stack in the loop in _get_win32_parent_processes(). Signed-off-by: Michael D Kinney

BaseTools/GenFw: Ignore R_*_NONE relocations on all architectures

2025-12-24T10:58:20+00:00

The ELF psABIs for all architectures stipulate that R_*_NONE relocations require no action at relocation time, and merely exist to declare a dependency on a symbol in a way that cannot be conveyed by the code itself (i.e., using an actual symbol reference). Given that EFI PE/COFF images are always fully linked binaries, such a dependency cannot be translated, and there are no known reasons why this would be necessary. So instead of ignoring such relocations specifically on x86_64 only, ignore them on all architectures when converting ELF binaries to PE/COFF. Fixes: #11878 Signed-off-by: Ard Biesheuvel

BaseTools,UefiPayloadPkg: Replace deprecated R_AARCH64_NONE value

2025-12-24T10:58:20+00:00

For nebulous reasons, the original ELF psABI deviated from common sense, and decided to #define R_AARCH64_NONE as '256', in spite of the fact that no other architecture uses anything other than 0x0. This has now been fixed in the psABI, so fix it in our code as well. Continuous-integration-options: PatchCheck.ignore-multi-package Signed-off-by: Ard Biesheuvel

BaseTools: GNUMakefiles must use CMD.EXE in Windows

2025-12-24T02:03:38+00:00

Use $(OS) in all GNUMakefiles to detect if the GNUMakefile is being used in a Windows OS. If a Windows OS is detected, then override SHELL to use cmd.exe. This prevents make utility from using sh.exe if sh.exe happens to be in PATH. If sh.exe is used, then backslash (\) characters in file paths are removed and builds break for files not found. Signed-off-by: Michael D Kinney

BaseTools: Fix multiple security vulnerabilities (Defense in Depth)

2025-12-22T04:53:27+00:00

Signed-off-by: 20000419

BaseTools/VfrCompile: Minor code cleanup

2025-12-03T12:29:51+00:00

There are no functional changes in this commit. It adds non-functional minor code cleanups made while tracking down the bugs fixed in the preceding commits. - Fix spelling 'arrary' -> 'array' where it occurs in the tool code and comments. - When renaming ExtractFieldNameAndArrary to ExtractFieldNameAndArrayIdx, we fix the typo and also clarify what the method does: it returns the field name and the array index when present. Since it is always used to populate a local variable named ArrayIdx, we stick to that spelling in the renamed method. - Add comment clarifying that mArrayNum holds array length (but again, don't go for a bigger global rename). - Rename CVfrVarDataTypeDB::GetFieldWidth to GetFieldType. It is only used once, and the new name correctly matches what it does. Signed-off-by: Mike Beaton

BaseTools/VfrCompile: Fix null pointer deref when dumping internal types

2025-12-03T12:29:51+00:00

Internal types such as pFormIdField, pFormSetGuidField have no associated field type, however the Dump command assumes that all types do. This causes null pointer dereferencing which can be caught by sanitizers. De facto, the field type for these types was already dumped as , this achieves the same safely. Signed-off-by: Mike Beaton

BaseTools/VfrCompile: Fix bit field access logic

2025-12-03T12:29:51+00:00

The previous logic for accessing bit fields is wrong when the bit field starts beyond the first byte, in a storage unit larger than a byte. This caused unaligned memory accesses which can be caught by sanitizers. We also bump the tool minor version number to reflect a functional bugfix. Signed-off-by: Mike Beaton

BaseTools/VfrCompile: Prevent uninitialized memory access

2025-12-03T12:29:51+00:00

When traversing through the field definition of a nested type, such as "MY_EFI_BITS_VARSTORE_DATA.BitsData.NestBitCheckbox", in method CVfrVarDataTypeDB::GetDataFieldInfo, the mBitWidth member of the parent (e.g. BitsData) of a bitfield is accessed, even though it is not itself a bit field and thus its mBitWidth has never been initialised. This is not necessary, the Size and Type of each parent object were being calculated then overwritten by the next lower object, so we can just avoid calculating these until the final one which we actually need. This behaviour was caught by clang MSan. Signed-off-by: Mike Beaton

BaseTools/VfrCompile: Fix EFI_GUID unaligned access

2025-12-03T12:29:51+00:00

The memmove in SetClassGuid at line 684 generates a `store to misaligned address` runtime warning when VfrCompile is compiled with clang UBSan. We can avoid generating code which stores to a misaligned address in a least a couple of other ways than done here, including casting the destination pointer of the memmove to (VOID *), or compiling with `-fno-builtin-memmove`. However, maintaining an unaligned pointer to an aligned type is, strictly speaking, undefined behaviour in the c/c++ standard (regardless of how it is or is not then accessed). So here we resolve the actual incorrect semantics of this part of the code (and thereby fix the unaligned access) by introducing a PACKED_EFI_GUID type in VfrUtilityLib.h, and using it for this unaligned access. Signed-off-by: Mike Beaton