Allow for automatic generation of the release name, release title, and
release notes (derived from the relevant section of the changelog).
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Add a rule to construct bin/version.txt containing the version number,
to allow a GitHub Actions workflow to verify that a tagged release
embeds a version number that matches the tag.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The all-drivers targets (e.g. ipxe.efi) cannot currently be used in a
Secure Boot build since the permissibility check will (correctly) fail
due to the inclusion of non-permitted drivers.
In a Secure Boot build, filter the all-drivers list to include only
the subset of drivers that are marked as being permitted for UEFI
Secure Boot.
Note that this automatic filter is a convenience shortcut: it is not
the enforcement mechanism. The filter exists only to provide a
meaningful definition for the otherwise unusable all-drivers targets
in Secure Boot builds. The enforcement mechanism remains the
permissiblity check introduced in commit 1d5b1d9 ("[build] Fail Secure
Boot builds unless all files are permitted").
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The core/version.c file is built into multiple objects (since it
incorporates the build target name such as "snponly.efi"), and is
handled separately from the standard build rules.
Add the missing line (taken from the standard build rules template) to
ensure that the dependency file is itself updated when the
dependencies change.
In particular, this ensures that the dependencies for core/version.c
will be updated when switching named configurations.
Reported-by: Christian I. Nilsson <ChristianN@2PintSoftware.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Commit dee71adda ("[build] Exclude external files from annotation
checks") excluded local top-level config headers from annotation
checks, but not local named config headers.
These are generated if missing when building with CONFIG= and will
most of the time be empty. Exclude these files from the list of
annotated files used to perform licensing and UEFI Secure Boot
eligibility checks.
Non-local named config headers intended to be used with Secure Boot
can be annotated with FILE_SECBOOT().
Signed-off-by: Christian I. Nilsson <ChristianN@2PintSoftware.com>
Modified-by: Michael Brown <mcb30@ipxe.org>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
External files such as embedded scripts or X.509 certificates are not
expected to include source file annotations such as FILE_LICENCE() or
FILE_SECBOOT(). Exclude these external files from the list of
annotated files used to perform licensing and UEFI Secure Boot
eligibility checks.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Using "git log" to automatically construct the build timestamp is of
minimal value. Reproducible builds should be using SOURCE_DATE_EPOCH
anyway, and for ad hoc builds it is arguable that the time at which
the build was performed is more relevant than the commit timestamp.
(For example, the user may be trying to deliberately use an older
version of iPXE in order to track down a regression via bisection.)
Remove the use of "git log", and thereby remove any requirement for
the git tools to be available at the point of building iPXE.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
As done for CROSS_COMPILE in commit 8fc11d8 ("[build] Allow for
per-architecture cross-compilation prefixes"), allow a default sysroot
for each architecture to be specified via the SYSROOT_<arch>
variables. These may then be provided as environment variables,
e.g. using
export SYSROOT_riscv32=/usr/riscv32-linux-gnu/sys-root
This is particularly useful for architectures such as RISC-V where the
64-bit compiler is also used to build 32-bit binaries, since in those
cases the compiler will default to using the 64-bit sysroot.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Add the Secure Boot permissibility check as a dependency for targets
built with the Secure Boot flag enabled. Attempting to build e.g.
make bin-x86_64-efi-sb/snponly.efi
will now fail unless all files used in the final binary are marked as
being permitted for Secure Boot.
This does not affect the standard build targets (without the "-sb"
suffix on the build directory).
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Tighten up the regular expression used to check for FILE_LICENCE() and
FILE_SECBOOT() declarations: ensure that they appear at the start of a
line (with optional whitespace) and include the expected opening
parenthesis.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The third-party 802.11 stack and NFS protocol code are known to
include multiple potential vulnerabilities and are explicitly
forbidden from being included in Secure Boot signed builds. This is
currently handled at the per-directory level by defining a list of
source directories (SRCDIRS_INSEC) that are to be excluded from Secure
Boot builds.
Annotate all files in these directories with FILE_SECBOOT() to convey
this information to the new per-file Secure Boot permissibility check,
and remove the old separation between SRCDIRS and SRCDIRS_INSEC.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Not all files within the iPXE codebase are allowed to be included in
UEFI Secure Boot signed builds.
Following the pattern used by the existing FILE_LICENCE() macro and
licensing check: define a FILE_SECBOOT() macro that can be used to
declare a file as being permitted (or forbidden) in a UEFI Secure Boot
signed build, and a corresponding build target to perform the check.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
We no longer have any requirement for common symbols. Disable common
symbols via the -fno-common compiler option, and simplify the test for
support of -fdata-sections (which can return a false negative when
common symbols are enabled).
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Parsing ELF data is simpler if we don't have to build a single binary
to handle both 32-bit and 64-bit ELF formats.
Allow for separate 32-bit and 64-bit binaries built from util/zbin.c
(as is already done for util/elf2efi.c).
Signed-off-by: Michael Brown <mcb30@ipxe.org>
GCC 15 generates a warning when a string initializer is too large to
allow for a trailing NUL terminator byte. This type of initializer is
fairly common in signature strings such as ACPI table identifiers.
Fix by disabling the warning.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
We currently disable all external trust sources (such as the UEFI
TlsCaCertificate variable) if an explicit TRUST=... parameter is
provided on the build command line.
Define an explicit TRUST_EXT build parameter that can be used to
explicitly disable external trust sources even if no TRUST=...
parameter is provided, or to explicitly enable external trust sources
even if an explicit TRUST=... parameter is provided. For example:
# Default trusted root certificate, disable external sources
make TRUST_EXT=0
# Explicit trusted root certificate, enable external sources
make TRUST=custom.crt TRUST_EXT=1
If no TRUST_EXT parameter is specified, then continue to default to
disabling external trust sources if an explicit TRUST=... parameter is
provided, to maintain backwards compatibility with existing build
command lines.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The EFI host utilities (such as elf2efi64, efirom, etc) include the
EDK2 headers, which include static assertions to ensure that they are
built with -fshort-wchar enabled. When building the host utilities,
we currently bypass these assertions by defining MDE_CPU_EBC. The EBC
compiler apparently does not support static assertions, and defining
MDE_CPU_EBC therefore causes EDK2's Base.h to define STATIC_ASSERT()
as a no-op.
Newer versions of the EDK2 headers omit the check for MDE_CPU_EBC (and
will presumably therefore fail to build with the EBC compiler). This
causes our host utility builds to fail since the static assertion now
detects that we are building with the host's default ABI (i.e. without
enabling -fshort-wchar).
Fix by enabling -fshort-wchar when building EFI host utilities. This
produces binaries that are technically incompatible with the host ABI.
However, since our host utilities never handle any wide-character
strings, this nominal ABI incompatiblity has no effect.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
We currently require the variable CROSS (or CROSS_COMPILE) to be set
to specify the global cross-compilation prefix. This becomes
cumbersome when developing across multiple CPU architectures,
requiring frequent editing of build command lines and preventing
incompatible architectures from being built with a single command.
Allow a default cross-compilation prefix for each architecture to be
specified via the CROSS_COMPILE_<arch> variables. These may then be
provided as environment variables, e.g. using
export CROSS_COMPILE_arm32=arm-linux-gnu-
export CROSS_COMPILE_arm64=aarch64-linux-gnu-
export CROSS_COMPILE_loong64=loongarch64-linux-gnu-
export CROSS_COMPILE_riscv32=riscv64-linux-gnu-
export CROSS_COMPILE_riscv64=riscv64-linux-gnu-
This change requires some portions of the Makefile to be rearranged,
to allow for the fact that $(CROSS_COMPILE) may not have been set
until the build directory has been parsed to determine the CPU
architecture.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Add basic support for running directly on top of SBI, with no UEFI
firmware present. Build as e.g.:
make CROSS=riscv64-linux-gnu- bin-riscv64/ipxe.sbi
The resulting binary can be tested in QEMU using e.g.:
qemu-system-riscv64 -M virt -cpu max -serial stdio \
-kernel bin-riscv64/ipxe.sbi
No drivers or executable binary formats are supported yet, but the
unit test suite may be run successfully.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Restructure the parsing of the build directory name from
bin[[-<arch>]-<platform>]
to
bin[-<arch>[-<platform>]]
and allow for a per-architecture default build platform.
For the sake of backwards compatibility, handle "bin-efi" as a special
case equivalent to "bin-i386-efi".
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Simplify the process of adding a new CPU architecture by providing
common implementations of typically empty architecture-specific header
files.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Some versions of ld will complain that the automatically created (and
unused by our build process) ELF program headers include a "LOAD
segment with RWX permissions".
Silence this warning by adding "-z separate-code" to the linker
options, where supported.
For BIOS builds, where the prefix will generally require writable
access to its own (tiny) code segment, simply inhibit the warning
completely via "--no-warn-rwx-segments".
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Move the platform-specific DHCP client architecture definitions to
header files of the form <ipxe/$(PLATFORM)/dhcparch.h>. This
simplifies the directory structure and allows the otherwise unused
arch/$(ARCH)/include/$(PLATFORM) to be removed from the include
directory search path, which avoids the confusing situation in which a
header file may potentially be accessed through more than one path.
For Linux userspace binaries on any architecture, use the EFI values
for that architecture by delegating to the EFI header file. This
avoids the need to explicitly select values for Linux userspace
binaries for each architecture.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The requirement to undo the implicit "-Dlinux" is not specific to the
x86 architecture. Move this out of the x86-specific Makefile.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The dangling pointer warning introduced in GCC 12 reports false
positives that result in build failures. In particular, storing the
address of a local code label used to record the current state of a
state machine (as done in crypto/deflate.c) is reported as an error.
There seems to be no way to mark the pointer type as being permitted
to hold such a value, so unconditionally disable the warning.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The array bounds checker on GCC 12 and newer reports a very large
number of false positives that result in build failures. In
particular, accesses through pointers to zero-length arrays (such as
those used by the linker table mechanism in include/ipxe/tables.h) are
reported as errors, contrary to the GCC documentation.
Work around this GCC issue by unconditionally disabling the warning.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The build process currently invokes the Python genkeymap.py script via
the Perl executable. Strangely, this appears to work.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Some versions of GNU objcopy (observed with binutils 2.23.52.0.1 on
CentOS 7.0.1406) document the -D/--enable-deterministic-archives
option but fail to recognise the short form of the option.
Work around this problem by using the long form of the option.
Reported-by: Olaf Hering <olaf@aepfle.de>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Commit 040cdd0 ("[linux] Add a prefix to all symbols to avoid future
name collisions") unintentionally reintroduced an element of
non-determinism into the build ID, by omitting the -D option when
manipulating the blib.a archive.
Fix by adding the -D option to restore determinism.
Reworded-by: Michael Brown <mcb30@ipxe.org>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Allow for the possibility of linking to platform libraries for the
Linux userspace build by adding an iPXE-specific symbol prefix.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Use the reference implementation of the EFI compression algorithm
(taken from the EDK2 codebase, with minor bugfixes to allow
compilation with -Werror) to compress EFI ROM images.
Inspired-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Support for building with the Intel C compiler (icc) was added in 2009
in the expectation that UEFI support would eventually involve
compiling iPXE to EFI Byte Code.
EFI Byte Code has never found any widespread use: no widely available
compilers can emit it, Microsoft refuses to sign EFI Byte Code
binaries for UEFI Secure Boot, and I have personally never encountered
any examples of EFI Byte Code in the wild.
The support for using the Intel C compiler has not been tested in over
a decade, and would almost certainly require modification to work with
current releases of the compiler.
Simplify the build process by removing this old legacy code.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Some patched versions of gcc (observed with gcc 9.3.0 on Ubuntu 20.04)
enable -fcf-protection=full by default. This breaks code that is not
explicitly written to expect the use of this flag. The breakage
occurs only at runtime if the affected code (such as setjmp()) happens
to execute, and is therefore a particularly pernicious class of bug to
be introduced into working code by a broken compiler.
Work around these broken patched versions of gcc by detecting support
for -fcf-protection and explicitly setting -fcf-protection=none if
found.
If any Ubuntu maintainers are listening: PLEASE STOP DOING THIS. It's
extremely unhelpful to have to keep working around breakages that you
introduce by modifying the compiler's default behaviour. Do what Red
Hat does instead: set your preferred CFLAGS within the package build
system rather than by patching the compiler to behave in violation of
its own documentation.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Several distributions include versions of gcc that are patched to
create position-independent executables by default. These have caused
multiple problems over the years: see e.g. commits fe61f6d ("[build]
Fix compilation when gcc is patched to default to -fPIE -Wl,-pie"),
5de1346 ("[build] Apply the "-fno-PIE -nopie" workaround only to i386
builds"), 7c395b0 ("[build] Use -no-pie on newer versions of gcc"),
and decee20 ("[build] Disable position-independent code for ARM64 EFI
builds").
The build system currently attempts to work around these mildly broken
patched versions of gcc for the i386 and arm64 architectures. This
misses the relatively obscure bin-x86_64-pcbios build platform, which
turns out to also require the same workaround.
Attempt to preempt the next such required workaround by moving the
existing i386 version to apply to all platforms and all architectures,
unless -fpie has been requested explicitly by another Makefile (as is
done by arch/x86_64/Makefile.efi).
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The function trace recorder build logic defaults to making "clean" a
dependency of the first build in a clean checkout. This is redundant
and causes problems if the build process spins up multiple make
invocations to handle multiple build architectures.
Fix by replacing with logic based on the known-working patterns used
for the ASSERT and PROFILE build parameters.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The version of awk used in FreeBSD seems to be incapable of formatting
unsigned 32-bit integers above 0x80000000 and will silently render any
such value as 0x80000000. For example:
echo 3735928559 | awk '{printf "0x%08x", $1}'
will produce 0x80000000 instead of the correct 0xdeadbeef.
This results in an approximately 50% chance of a build ID collision
when building on FreeBSD.
Work around this problem by passing the decimal value directly in the
ld --defsym argument value.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The elftoolchain version of objcopy (as used in FreeBSD) seems to be
unusable for generating a raw binary file, since it will apparently
ignore the load memory addresses specified for each section in the
input file.
The binutils version of objcopy may be used on FreeBSD by specifying
OBJCOPY=/usr/local/bin/objcopy
Detect an attempt to use the unusable elftoolchain version of objcopy
and report it as an error.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Calculate the build ID as a checksum over the input files. Since the
input files include $(BIN)/version.%.o which itself includes the build
target name (from which TGT_LD_FLAGS is calculated), this should be
sufficient to meet the requirement that the build ID be unique for
each $(BIN)/%.tmp even within the same build run.
Modified-by: Michael Brown <mcb30@ipxe.org>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
When using $(shell), make will first invoke BUILD_ID_CMD and then have
the value defined when calling $(LD). This means we get to see the
_build_id when building with make V=1. Previously the build_id was
figured out as a subshell command run during the recipe execution
without being able to see the build_id itself.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Directories may be left behind by failed filesystem image builds, and
will not currently be successfully removed by a "make clean".
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Make the contents of $(BLIB) deterministic to allow it to be
subsequently used for calculating a build ID.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
At the moment '\s*' is silently interpreted as just 's*', but in the
future it will be an error:
sed: 1: "s/\.o\s*:/_DEPS +=/": RE error: trailing backslash (\)
cf. https://bugs.freebsd.org/229925
Signed-off-by: Tobias Kortkamp <t@tobik.me>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
gcc10 switched default behavior from -fcommon to -fno-common. Since
"__shared" relies on the legacy behavior, explicitly specify it.
Signed-off-by: Bruce Rogers <brogers@suse.com>
Modified-by: Michael Brown <mcb30@ipxe.org>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Michael Brown
Christian I. Nilsson
Bernhard M. Wiedemann
Manuel Mendez
Tobias Kortkamp
Bruce Rogers