Using GCC 13.3.0 discovers an out of bounds memory access in VfrCompile
when building DriverSampleDxe. This is also discoverable with ASan.
The issue here is that EFI_IFR_TYPE_VALUE is a flexible type and
when passed by value for string types only the header part is accessible.
Assuming the remainder is zero seems to be ok as gZeroEfiIfrTypeValue
is used as a variable source.
This change also fixes a warning for new[]/delete[] mismatch
discovered by ASan.
Signed-off-by: Vitaly Cheptsov <vit9696@protonmail.com>
BaseTools has been duplicating and adapting code that is defined in
MdePkg and MdeModulePkg. This leads to desync issues where the same
symbols may be backed by different functions with slightly different
semantics and also fixes that apply only to BaseTools or only to MdePkg
and MdeModulePkg.
To address these issues, update BaseTools/Source/C to utilize the code
from MdePkg and MdeModulePkg.
Signed-off-by: Marvin Häuser <mhaeuser@posteo.de>
BaseTools has been duplicating and adapting code that is defined in
MdePkg and MdeModulePkg. This leads to desync issues where the same
symbols may be backed by different functions with slightly different
semantics and also fixes that apply only to BaseTools or only to MdePkg
and MdeModulePkg.
To address these issues, update BaseTools/Source/C to utilize the code
from MdePkg and MdeModulePkg.
Signed-off-by: Marvin Häuser <mhaeuser@posteo.de>
Update the brotli submodule to the latest commit (ed1995b6bda1)
so that the build isn't broken in GCC 12 compilers.
Signed-off-by: Savva Mitrofanov <savvamtr@gmail.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>
This change added the build script to cross compile the base tool
binaries for Linux ARM/AARCH64 systems.
The needed libuuid system library is pulled from source file and rebuilt
to support the corresponding library dependencies. Individual tools'
makefiles are also updated to link the cross compiled library as well.
The EDK2 base tool build script was also updated to support such change.
This was tested functional on Linux ARM host system.
Cc: Rebecca Cran <rebecca@bsdio.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Yuwei Chen <yuwei.chen@intel.com>
Signed-off-by: Kun Qin <kun.qin@microsoft.com>
This change adds the support of crossbuilding basetool for Windows ARM/
ARM64 systems, which will enable the generally available pipeline agents
to build binary tools and make releases as they see fit.
The EDK2 base tools build script is also updated to support cross
compilation using this script.
The crossbuilt binary output is tested on Windows ARM based hardware
systems.
Cc: Rebecca Cran <rebecca@bsdio.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Yuwei Chen <yuwei.chen@intel.com>
Signed-off-by: Kun Qin <kun.qin@microsoft.com>
This change focuses on the support of building basetool natively for
Windows ARM/ARM64 host system, which will enable the ARM based platforms
to build UEFI and unit tests.
Note that the warnings due to integer conversions are suppressed for
this specific target to avoid too much local changes carried in MU. The
formal change should drop all these binaries and move to pythonic
scripts.
The binary output is tested on Windows ARM based hardware systems.
Cc: Rebecca Cran <rebecca@bsdio.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Yuwei Chen <yuwei.chen@intel.com>
Signed-off-by: Kun Qin <kun.qin@microsoft.com>
GenFw relies on static ELF relocation tables emitted by the linker (via
the --emit-relocs command line switch). These are different from the
dynamic relocations that a dynamic loader uses: static relocations are
emitted by the compiler/assembler, and consumed by the linker to
construct the executable. Only when the load address is a priori unknown
are dynamic relocations emitted, by the linker, in a format that the
dynamic loader can consume.
This distinction is relevant because only dynamic relocations cover the
GOT, and so GOT based indirections are better avoided. Unfortunately,
there are cases where the toolchain insists on emitting GOT based symbol
references, and so we have to deal with them in one of 2 ways:
- replace GOT based symbol references with direct references, so that
the GOT entries themselves are no longer used, and can be ignored when
generating the PE/COFF relocation tables (AARCH64 and RISCV64 take
this approach);
- infer the locations of the GOT slots from the references appearing in
the code, and emit PE/COFF relocations for them so that their contents
will be fixed up appropriately.
The latter is the approach taken by GenFw for x86_64, which is the only
feasible approach for its ISA, given that GOT slots can be used as
memory operands in many different types of instructions, not all of
which can be converted straight-forwardly.
E.g.,
movq foo@GOTPCREL(%rip), %rax
can always be converted into
leaq foo(%rip), %rax
whereas
cmpq foo@GOTPCREL(%rip), %rax
can only be converted under the 32-bit position dependent code model,
into
cmpq $foo, %rax
and so the GOT references cannot be elided when generating position
independent code, which is what GenFw requires.
To remove the need for the linker to guess where the instructions start,
the ELF psABI for x86_64 specifies a couple of relaxable alternatives
for GOTPCREL, which are used to annotate particular classes of GOT
referencing instructions that may be relaxed to their non-GOT
counterparts.
There is no specification for what --emit-relocs is supposed to produce,
or whether or not its output is supposed to reflect such relaxations.
ld.bfd and LLD behave differently in this regard, and the latter may
emit R_X86_64_REX_GOTPCRELX relocations for MOV instructions that it
already has relaxed into LEA instructions. This means the displacement
in the instruction no longer refers to the GOT slot, but directly to the
object itself, and emitting a relocation is not only unnecessary, but
also harmful as the PE/COFF loader will corrupt the object when it
applies the relocations at startup.
Under the position independent code model, the only relaxation that the
linker could have applied for a R_X86_64_REX_GOTPCRELX relocation is MOV
to LEA, so detect whether the instruction is already LEA, and ignore the
relocation if that is the case.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
This is part of a sequence of commits to restore build on the XCODE5
toolchain.
The definition is required on other toolchains, but on XCODE5 results
in a macro redefined error (from the existing value 255) from
/usr/include/stdint.h.
Signed-off-by: Mike Beaton <mjsbeaton@gmail.com>
This patch is to sync RETURN_ERROR macro with the
MdePkg/Include/Base.h
Ref: 1a89d9887f MdePkg:Update Return Error Macro in Base.h
Fixing RETURN_ERROR macro.
It is causing problem in Coverity Static analysis tool
as we are directly converting the UINT value to INTN.
Changing value from UINT to INTN might cause problema
Here we know that the values would not be in loss of data.
To increase the code quality and increase the static tool
analysis score we have to change it
Cc: Rebecca Cran <rebecca@bsdio.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Yuwei Chen <yuwei.chen@intel.com>
Signed-off-by: Abdul Lateef Attar <AbdulLateef.Attar@amd.com>
Per TCBZ2372, clang on Linux emits a warning if an enum-typed variable
is compared with a constant outside of the range of the enum. Such
comparisons are performed in multiple locations in DXE core on
variables of type EFI_MEMORY_TYPE. This patch moves the OEM and OS
reserved types into the EFI_MEMORY_TYPE enum itself to resolve this
issue and improve readability. This commit does this for the BaseTools
copy of this enum.
Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com>
When converting ELF to PE/COFF for the AArch64 target, we may encounter
an R_AARCH64_ADR_GOT_PAGE relocation that refers to an ADR instruction
instead of an ADRP instruction. This can happen when the toolchain is
working around Cortex-A53 erratum #843419. If that's the case, be sure
to calculate the offset appropriately.
This resolves an issue experienced when building a StandaloneMm image
(which is built with -fpie) with stack protection enabled on GCC
compiled with "--enable-fix-cortex-a53-843419". In this case, the linker
may convert an ADRP instruction appearing at an offset of 0xff8 or 0xffc
modulo 4KiB into an ADR instruction, but will leave the original
R_AARCH64_ADR_GOT_PAGE relocation in place. (This is not a bug in the
linker, given that there is no other relocation type that it could
reasonably convert it into)
In this scenario, the following code is being generated by the
toolchain:
# Load to set the stack canary
2ffc: 10028020 adr x0, 8000 <mErrorString+0x1bc>
3008: f940d400 ldr x0, [x0, #424]
# Load to check the stack canary
30cc: b0000020 adrp x0, 8000 <mErrorString+0x1bc>
30d0: f940d400 ldr x0, [x0, #424]
GenFw rewrote that to:
# Load to set the stack canary
2ffc: 10000480 adr x0, 0x308c
3008: 912ec000 add x0, x0, #0xbb0
# Load to check the stack canary
30cc: f0000460 adrp x0, 0x92000
30d0: 912ec000 add x0, x0, #0xbb0
Note that we're now setting the stack canary from the wrong address,
resulting in an erroneous stack fault.
After this fix, the offset will be calculated correctly for an ADR and
the stack canary is set correctly. Note that there is a corner case
where this may cause the conversion to fail: if the original GOT entry
is just within -/+ 1 MiB of the reference, but the actual variable it
refers to is not, the resulting offset cannot be represented by the
immediate offset field in a ADR instruction. Given that this issue only
affects PIE executables, which are rare and usually tiny, this is
unlikely to cause problems in practice.
Ref: https://edk2.groups.io/g/devel/topic/102202314
[ardb: expand commit log, add reference]
Signed-off-by: Jake Garver <jake@nvidia.com>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
Automatically set the nxcompat flag in the DLL Characteristics field of
the Optional Header of the PE32+ image. For this flag to be set
automatically, the section alignment must be evenly divisible
by 4K (EFI_PAGE_SIZE) and no section must be executable and writable.
Adds a command line flag to GenFw, --nonxcompat, to ensure the
IMAGE_DLLCHARACTERISTICS_NX_COMPAT bit is not set, even if all
requirements are met. Updates the manual for GenFw to include the new
flag.
Cc: Rebecca Cran <rebecca@bsdio.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Yuwei Chen <yuwei.chen@intel.com>
Signed-off-by: Joey Vagedes <joeyvagedes@gmail.com>
Acked-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
Correct relax id from 99 to 100 and added relocation support up to 109
fix gcc14 adds new relocation, and the generated relocation
causes the build and compilation to fail.
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4559
Cc: Rebecca Cran <rebecca@bsdio.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Yuwei Chen <yuwei.chen@intel.com>
Cc: Chao Li <lichao@loongson.cn>
Signed-off-by: Dongyan Qian <qiandongyan@loongson.cn>
Reviewed-by: Chao Li <lichao@loongson.cn>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4494
Today for SEC core(not VTF-0), GenFv finds free 4K aligned space in
FV for AP waking vector and JMP to 4G-30h in the waking vector.
There is no usage of this today. Remove the logic to avoid confusing
and save spaces in reset vector.
Cc: Rebecca Cran <rebecca@bsdio.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Yuwei Chen <yuwei.chen@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
Use the MdePkg versions instead of maintaining a copy in BaseTools.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
Use the MdePkg version instead of maintaining a copy in BaseTools.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Chao Li <lichao@loongson.cn>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
Use the newer versions of the machine #defines.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Chao Li <lichao@loongson.cn>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
The #define for IMAGE_FILE_MACHINE_ARM is not present in MdePkg,
this looks like a relic not used any more. Remove.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
Use the MdePkg version instead of maintaining a copy in BaseTools.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Sunil V L <sunilvl@ventanamicro.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
Use the MdePkg version instead of maintaining a copy in BaseTools.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Chao Li <lichao@loongson.cn>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
Appears to be a relic for ancient windows / compiler versions,
windows builds in CI work just fine without it.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
threading.currentThread is a deprecated alias for
threading.current_thread, and causes a warning to be displayed when it's
called. Update NmakeSubdirs.py to use the latter method instead.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4405
The PE/COFF spec describes an additional DllCharacteristics field
implemented as a debug directory entry, which carries flags related to
which control flow integrity (CFI) features are supported by the binary.
So let's add this entry when doing ELF to PE/COFF conversion - we will
add support for setting the flags in a subsequent patch.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Reviewed-by: Oliver Smith-Denny <osde@linux.microsoft.com>
Reviewed-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4405
When performing ELF to PE/COFF conversion, parse any notes sections to
decide whether the image supports forward CFI landing pads. This will be
used to set the associated DllCharacteristicsEx flag in a subsequent
patch.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Reviewed-by: Oliver Smith-Denny <osde@linux.microsoft.com>
Acked-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Update the antlr makefile to remove the explicit setting of CC to either
clang or gcc. This causes it to use /usr/bin/cc or whatever the user has
set $(CC) to.
This removes the last dependency on gcc for BaseTools.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
clang 17 defaults to C++17, where the 'register' keyword is deprecated
and the warning changed to an error. To avoid build errors, compile
against C++14 by specifying '-std=c++14' in CXXFLAGS.
Signed-off-by: Rebecca Cran <rebecca@quicinc.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
In https://bugzilla.tianocore.org/show_bug.cgi?id=2842 clang support was
added by having users specify "make CXX=llvm" when building BaseTools.
The Makefile then sees that and sets CC=$(CLANG_BIN)clang and
CXX=$(CLANG_BIN)clang++. That requires that the executables 'clang' and
'clang++' exist and for example aren't named 'clang-17' and
'clang++-17'. Also, it's an unusual way of specifying the compiler,
since many users will expect to be able to override CC and CXX on the
make command line.
Rework the BaseTools Makefiles removing the 'BUILD_' prefix (BUILD_CC
and BUILD_CXX) and using the standard name 'LDFLAGS' instead of
'LFLAGS'. This allows clang to be used by running
'make -C BaseTools CC=clang CXX=clang++'.
Signed-off-by: Rebecca Cran <rebecca@quicinc.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
In https://bugzilla.tianocore.org/show_bug.cgi?id=2842 clang support was
added by having users specify "make CXX=llvm" when building BaseTools.
The Makefile then sees that and sets CC=$(CLANG_BIN)clang and
CXX=$(CLANG_BIN)clang++. That requires that the executables 'clang' and
'clang++' exist and for example aren't named 'clang-17' and
'clang++-17'. Also, it's an unusual way of specifying the compiler,
since many users will expect to be able to override CC and CXX on the
make command line.
Rework the BaseTools Makefiles removing the 'BUILD_' prefix (BUILD_CC
and BUILD_CXX) and using the standard name 'LDFLAGS' instead of
'LFLAGS'. This allows clang to be used by running
'make -C BaseTools CC=clang CXX=clang++'.
Signed-off-by: Rebecca Cran <rebecca@quicinc.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
While more portable methods exist to handle these cases, this change
does not attempt to do more than fix the immediate problem and
follow the conventions already established in this code.
`snprintf()` is introduced as the minimum improvement apart from
making the buffers larger.
Fixes the following CodeQL alerts:
1. Failure on line 2339 in
BaseTools/Source/C/VfrCompile/Pccts/antlr/gen.c
- Type: Potentially overrunning write
- Severity: Critical
- Problem: This 'call to sprintf' operation requires 17 bytes but
the destination is only 16 bytes.
2. Failure on line 2341 in
BaseTools/Source/C/VfrCompile/Pccts/antlr/gen.c
- Type: Potentially overrunning write
- Severity: Critical
- Problem: This 'call to sprintf' operation requires 17 bytes but
the destination is only 16 bytes.
3. Failure on line 1309 in
BaseTools/Source/C/VfrCompile/Pccts/antlr/main.c
- Type: Potentially overrunning write
- Severity: Critical
- Problem: This 'call to sprintf' operation requires 25 bytes but
the destination is only 20 bytes.
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Sean Brogan <sean.brogan@microsoft.com>
Cc: Yuwei Chen <yuwei.chen@intel.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Oliver Smith-Denny <osd@smith-denny.com>
