Michael Brown [Thu, 26 Feb 2026 13:11:57 +0000 (13:11 +0000)]
[cachedhcp] Automatically open network device matching cached DHCPACK
It is unintuitive to have to include an "ifopen" at the start of an
autoexec.ipxe script. Provide a mechanism for upper-layer drivers to
mark a network device to be opened automatically upon registration,
and do so for the device to which the cached DHCPACK is applied.
Michael Brown [Thu, 26 Feb 2026 12:28:50 +0000 (12:28 +0000)]
[dynui] Allow for duplicate shortcut keys
When searching for a shortcut key, search first from the currently
selected menu item and then from the start of the list.
This allows several ways for a shortcut key to be meaningfully used
multiple times within the same menu. For example, two sections may
have the same shortcut key:
item --key s --gap (S)ection 1
item ...
item ...
item --key s --gap (S)ection 2
item ...
With the above menu, repeated "s" keypresses would cycle through the
sections.
As another example, entries within different sections may have the
same shortcut keys. For example:
item --key d --gap (D)ebian
item --key s debst Debian (s)table release
item --key u debun Debian (u)nstable release
item --key f --gap (F)edora
item --key s fedst Fedora (s)table release
item --key u fedun Fedora (u)nstable release
With the above menu, a shortcut key sequence such as "f", "s" can be
used to select an entry within a specific section, avoiding the need
to choose shortcut keys that are globally unique within the menu.
Michael Brown [Wed, 25 Feb 2026 17:05:59 +0000 (17:05 +0000)]
[efi] Allow for the existence of multiple shim lock protocols
When multiple shims are present in the system (e.g. in a boot chain
such as UEFI -> iPXE shim -> iPXE -> distro shim -> distro kernel),
there may be more than one installed shim lock protocol.
There is no sensible way to identify which shim lock protocol belongs
to which shim. The shim lock protocol is installed on an anonymous
handle that has no device path, no other form of identifier, and no
connection to any other handle or protocol instance installed by the
shim.
The shim does include some extremely convoluted logic whereby a second
shim will attempt to uninstall a shim lock protocol installed by an
earlier shim. However, this logic is broken: the second shim calls
UninstallProtocolInterface() with the wrong handle and the wrong
protocol interface pointer. This logic error is silently ignored
since shim does not bother to check the return status.
Experience shows that there is unfortunately no point in trying to get
a fix for this upstreamed into shim, or even in raising the issue with
the shim project. We therefore work around the shim bug by calling
all instances of the shim lock protocol, rather than relying on shim
itself to ensure that only one such instance exists.
Michael Brown [Wed, 25 Feb 2026 00:14:26 +0000 (00:14 +0000)]
[xferbuf] Silently discard data written to a void data transfer buffer
Allow data to be successfully written (and discarded) to a void data
transfer buffer, rather than throwing an error. This allows a void
data transfer buffer to be used when determining the length of a file
downloaded from a TFTP server that does not support the "tsize" option
defined in RFC 2349.
Michael Brown [Wed, 25 Feb 2026 00:00:28 +0000 (00:00 +0000)]
[xferbuf] Record maximum required size
Record the maximum size required when writing into a data transfer
buffer. This allows the maximum size to be determined even if
allocation fails (e.g. due to a fixed-size buffer or an out-of-memory
condition).
In the case of a fixed-size buffer (which may already be larger than
required), this allows the caller to determine the actual size used
for written data.
Michael Brown [Tue, 24 Feb 2026 15:53:25 +0000 (15:53 +0000)]
[ci] Remove now-redundant "netboot" job
Use the ipxeboot.tar.gz artifact created by util/gensrvimg in the
"combine" job, and delete the dedicated "netboot" job that currently
creates the same artifact.
Michael Brown [Mon, 23 Feb 2026 16:00:02 +0000 (16:00 +0000)]
[build] Create util/gensrvimg for building network boot server images
In the spirit of util/genfsimg, create a script util/gensrvimg that
can be used to install compiled iPXE binaries to a directory tree
suitable for copying to a TFTP or HTTP server.
The script detects the CPU architecture for each input file and
installs it into the appropriate subdirectory. Top-level symlinks are
created for each filename, with earlier files taking precedence.
Signed binaries are detected and automatically placed into a Secure
Boot specific subdirectory, thereby allowing the reduced-feature
Secure Boot binaries to coexist with full-feature binaries in a single
installation directory tree. An iPXE shim may be specified and will
be automatically installed alongside the signed binaries, with the
relevant symlink created for each signed binary.
Dexter Gerig [Tue, 24 Feb 2026 09:33:39 +0000 (09:33 +0000)]
[tls] Remove current time from client random bytes
TLS versions 1.2 and earlier define a 4-byte gmt_unix_time field as
part of the 32-byte ClientHello random data block, as a (minimal) form
of protection against a broken random number generator. iPXE has
never set this field to a correct value. Early versions had only
relative timers and so set this field to zero. Commit 5da7123 ("[tls]
Include current time within the client random bytes") did set this
field to the current time, but neglected to use the correct byte
ordering.
TLS version 1.3 (defined in RFC 8446) omits the gmt_unix_time field
completely and just defines the whole 32-byte value as random data.
Simplify the code by using the approach defined in RFC 8446.
Modified-by: Michael Brown <mcb30@ipxe.org> Signed-off-by: Michael Brown <mcb30@ipxe.org>
RA contains MTU setting, this is especially needed in some networks
which don't have a a full 1500 MTU link to IPv6 internet. Mostly due
to some providers (such as Microsoft Azure) not having a working pMTUd
setup.
Signed-off-by: Christian I. Nilsson <nikize@gmail.com> Modified-by: Michael Brown <mcb30@ipxe.org> Signed-off-by: Michael Brown <mcb30@ipxe.org>
Joseph Wong [Fri, 20 Feb 2026 18:15:17 +0000 (10:15 -0800)]
[bnxt] Remove access of deprecated link speed variables
Remove access of deprecated link speed variables for 5750x devices.
Update test flag to include CHIP_P5_PLUS when excluding access of
certain NVM variables.
Signed-off-by: Joseph Wong <joseph.wong@broadcom.com>
Joseph Wong [Fri, 20 Feb 2026 08:22:08 +0000 (00:22 -0800)]
[bnxt] Correct port index usage
Use port index value retrieved from the firmware when calling
bnxt_hwrm_queue_qportcfg() to retrieve the queue_id. This function
is available for all devices.
Signed-off-by: Joseph Wong <joseph.wong@broadcom.com>
Michael Brown [Sun, 22 Feb 2026 23:13:00 +0000 (23:13 +0000)]
[pxeprefix] Add a minimal iPXE NBP metadata header
There is no fixed structure for a PXE NBP: the format is just an
opaque block of executable code that is loaded into memory verbatim
and executed by jumping to the first byte. It is consequently
impossible for external code to unambiguously identify a PXE NBP, or
to inspect any metadata about the NBP's functionality.
The first five bytes of an iPXE NBP are already fixed as being an ljmp
instruction that resets the code segment to 0x7c0 and continues
execution from the following byte. We can extend this to include a
minimal header as follows:
This is backwards-compatible to existing binaries (which effectively
have zero bytes of metadata following the ljmp instruction), and
allows for future expansion by appending metadata fields (with the
ljmp offset used to determine the overall header length and therefore
the presence of further fields).
In this initial version of the header, define a magic value (used to
differentiate an iPXE NBP from other binaries that happen to start
with an ljmp instruction), and a single-byte value that encodes
whether this binary is built for 32-bit or 64-bit CPUs.
Michael Brown [Sun, 22 Feb 2026 21:25:48 +0000 (21:25 +0000)]
[build] Use little-endian word values in genfsimg
The genfsimg script extracts 16-bit word values from binary files
using the POSIX-compatible subset of options to "od". This subset
does not include the "--endian" option supported by GNU od. The
16-bit values are therefore effectively extracted and compared as byte
sequences. Since all quantities in PE files are little-endian, this
requires all literals to be written in a byte-reversed form.
Switch to implementing get_word() in a marginally less efficient way
(by issuing two separate calls to get_byte()), so that the value
returned is the real 16-bit word value. This allows several of the
constants to be written in a more meaningful form (e.g. "8664" for
x86_64, "aa64" for AArch64, etc).
Michael Brown [Fri, 20 Feb 2026 15:14:42 +0000 (15:14 +0000)]
[ci] Add a job to automatically create releases
Add a job that will automatically create a (draft) release for any
suitable tag, using the build artifacts and release notes already
constructed by earlier jobs. Minimise the logic within the release
job itself, since by definition it cannot be tested on every commit.
Michael Brown [Fri, 20 Feb 2026 17:37:00 +0000 (17:37 +0000)]
[ci] Remove redundant duplicate creation of version.txt
The version.txt file is now created by the "version" job (which also
generates the release name, release title, and release notes). Remove
the now-redundant generation of version.txt in the BIOS build job.
Michael Brown [Thu, 19 Feb 2026 12:54:02 +0000 (12:54 +0000)]
[build] Allow for construction of a text file containing the version
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.
Michael Brown [Wed, 18 Feb 2026 18:30:46 +0000 (18:30 +0000)]
[ci] Create a network bootable files archive as a build artifact
Create an archive designed to be extracted to a web server (or TFTP
server) directory, containing the network bootable files such as
undionly.kpxe, ipxe.efi, etc.
Incorporate the iPXE shim binaries, complete with the required
symlinks such as snponly-shim.efi -> shimx64.efi.
Michael Brown [Wed, 18 Feb 2026 18:22:19 +0000 (18:22 +0000)]
[ci] Include latest iPXE shim in build artifacts
Prepare for the possibility of creating ISO and USB disk images that
support UEFI Secure Boot by downloading the Microsoft-signed binaries
from the latest release of the iPXE shim.
Michael Brown [Wed, 18 Feb 2026 00:27:04 +0000 (00:27 +0000)]
[ci] Use ipxe-builder-utils container for combined BIOS/UEFI images
We currently use the ipxe-signer container for the step that combines
the BIOS and UEFI build artifacts to produce the multi-architecture
ISO and USB images.
Switch to using the generic architecture-independent utility toolchain
container, thereby allowing the ipxe-signer container to minimise its
attack surface by removing tools that are not required for the signing
operation.
Michael Brown [Tue, 17 Feb 2026 15:00:08 +0000 (15:00 +0000)]
[ci] Include CA certificate file alongside signed binaries
Include the relevant CA certificate in the UEFI Secure Boot build
artifacts. This allows for easy identification of test-signed builds
without having to extract the certificate from the signed binary.
This also eases the process of adding the ephemeral test-signing
certificate to the UEFI trusted certificate list, if a user wants to
test a non-release build with Secure Boot enabled. (The corresponding
private key is deliberately not preserved, to minimise the attack
surface that this would otherwise open up on the user's system.)
Include the commit hash and build architecture within the ephemeral
test-signing certificate's subject name, to make it obvious that the
scope is limited to signing only that single build.
Michael Brown [Sun, 15 Feb 2026 22:50:12 +0000 (22:50 +0000)]
[ci] Add support for building UEFI Secure Boot signed binaries
Add a job that takes the bin-x86_64-efi-sb and bin-arm64-efi-sb build
artifacts and signs them for UEFI Secure Boot.
The hardware token containing the trusted signing key is attached to a
dedicated self-hosted GitHub Actions runner. Only tagged release
versions (and commits on the "sbsign" testing branch) will be signed
on this dedicated runner. All other commits will be signed on a
standard GitHub hosted runner using an ephemeral test certificate that
is not trusted for UEFI Secure Boot.
No other work is done as part of the signing job. The iPXE source
code is not even checked out, minimising any opportunity to grant
untrusted code access to the hardware token.
The hardware token password is held as a deployment environment
secret, with the environment being restricted to allow access only for
tagged release versions (and commits on the "sbsign" testing branch)
to provide an additional layer of security.
The signing certificates and intermediate certificates are obtained
from the iPXE Secure Boot CA repository, with the certificate selected
via deployment environment variables.
To minimise hidden state held on the self-hosted runner, the pcscd
service is run via a service container, with the hardware token passed
in via "--devices /dev/bus/usb".
Select the deployment environment name (and hence runner tag) via a
repository variable SBSIGN_ENVIRONMENT, so that forks do not attempt
to start jobs on a non-existent self-hosted runner.
Michael Brown [Fri, 13 Feb 2026 23:37:46 +0000 (23:37 +0000)]
[ci] Schedule Coverity Scan run via GitHub Actions
Trigger the daily Coverity Scan submission via a GitHub Actions
schedule (or via a manual workflow run), rather than relying on an
external process pushing to the "coverity_scan" branch.
Since the scheduled workflow will run even on forks of the repository,
add a check to cause the submission to be skipped if the relevant
secret is not configured.
Michael Brown [Fri, 13 Feb 2026 18:09:37 +0000 (18:09 +0000)]
[build] Include USB drivers in the all-drivers build by default
Including USB drivers has some unavoidable side effects. With a BIOS
firmware, attaching the host controller drivers will necessarily
disable the SMM-based USB legacy support which emulates a PS/2
keyboard. With a UEFI firmware, loading the host controller drivers
may disconnect some of the less compliant vendor USB device drivers.
We have historically erred on the side of caution and avoided
including any USB drivers in the all-drivers build. Time has moved
on, USB NICs have become more common (especially for laptops, which
now rarely include physical Ethernet ports), and the UEFI Secure Boot
model makes it prohibitively difficult for users to compile their own
binaries to add support for non-default drivers.
Switch to including USB drivers by default in the all-drivers build.
Provide a fallback build target that matches the existing driver set
(i.e. excluding any USB drivers) and can be built using e.g.:
Michael Brown [Fri, 13 Feb 2026 13:43:37 +0000 (13:43 +0000)]
[build] Handle all driver list construction via parserom.pl
Handle construction of the EFI, Linux, Xen, and VMBus driver build
rules via parserom.pl to ensure consistency. In particular, this
allows those drivers to appear in the DRIVERS_SECBOOT list used to
filter out non-permitted drivers in a Secure Boot build.
Michael Brown [Fri, 13 Feb 2026 14:04:07 +0000 (14:04 +0000)]
[build] Mark Xen HVM files as permitted for UEFI Secure Boot
The Xen netfront driver and the core architecture-independent files
such as xenstore.c and xenbus.c are already marked as permitted for
UEFI Secure Boot, but the x86-specific HVM driver (which attaches to
the PCI device and instantiates the Xen devices) is not.
Review the HVM-specific files and mark them as permitted for UEFI
Secure Boot.
Michael Brown [Thu, 12 Feb 2026 15:45:28 +0000 (15:45 +0000)]
[slirp] Disable warnings for uncleanly deprecated libslirp functions
libslirp introduced a new API for constructing polling lists, to
accommodate Windows platforms where a handle descriptor may be too
large for an int.
Older versions of libslirp do not have the new API calls, and the
older API calls were immediately marked as deprecated, with no
overlap. We would therefore need to use #ifdef and always have some
code that is deliberately not compiled, depending on the version of
libslirp that we find on the user's system. This is highly
undesirable.
Work around this by disabling the deprecation warning (which is what
libslirp itself does for the portions of its code that necessarily
touch the deprecated functions).
Michael Brown [Thu, 12 Feb 2026 12:06:41 +0000 (12:06 +0000)]
[build] Include PCI drivers only in BIOS and UEFI builds
We currently have no PCI bus abstractions for Linux userspace or for
RISC-V SBI. Limit PCI drivers to being included in the all-drivers
build only for BIOS and UEFI platforms.
Michael Brown [Thu, 12 Feb 2026 13:26:12 +0000 (13:26 +0000)]
[dt] Add DT_ROM() and DT_ID() macros
Add DT_ROM() and DT_ID() macros following the pattern for PCI_ROM()
and PCI_ID(), to allow for the possibility of including devicetree
network devices within the "all-drivers" build of iPXE.
Michael Brown [Thu, 12 Feb 2026 12:48:16 +0000 (12:48 +0000)]
[build] Include Xen and Hyper-V drivers only in x86 BIOS and UEFI builds
The Xen and Hyper-V drivers cannot be included in the Linux userspace
build since they require MMIO accesses. Limit these drivers to being
included in the all-drivers build only for BIOS and UEFI platforms.
Michael Brown [Thu, 12 Feb 2026 11:44:37 +0000 (11:44 +0000)]
[build] Include ISA drivers only in 32-bit BIOS builds
ISA hardware is vanishingly unlikely to be encountered in anything
other than pre-64-bit x86 hardware with a BIOS firmware. Exclude the
ISA drivers from all other builds.
Michael Brown [Wed, 11 Feb 2026 22:35:10 +0000 (22:35 +0000)]
[build] Filter out non-permitted drivers for UEFI Secure Boot
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").
Michael Brown [Wed, 11 Feb 2026 20:46:58 +0000 (20:46 +0000)]
[build] Drag in Xen and Hyper-V support via network device drivers
Include Xen and Hyper-V support in the all-drivers build by dragging
in the netfront and netvsc drivers, since these are the functional
drivers that provide network interfaces.
Michael Brown [Wed, 11 Feb 2026 15:38:58 +0000 (15:38 +0000)]
[build] Construct driver lists for each bus type
Include the underlying bus type (e.g. "pci" or "isa") within the lists
constructed to describe the available drivers, to allow for the
possibility that platforms may want to define a platform-specific
subset of drivers to be present in the all-drivers build. For
example, non-x86 platforms such as RISC-V SBI do not need to include
the ISA network drivers since the corresponding hardware cannot ever
be present on a RISC-V system.
Michael Brown [Wed, 11 Feb 2026 15:19:13 +0000 (15:19 +0000)]
[usb] Add USB_ROM() and USB_ID() macros
Add USB_ROM() and USB_ID() macros following the pattern for PCI_ROM()
and PCI_ID(), to allow for the possibility of including USB network
devices within the "all-drivers" build of iPXE.
Michael Brown [Tue, 10 Feb 2026 10:00:27 +0000 (10:00 +0000)]
[librm] Work around two errata in the 386's "popal" instruction
Detailed experiments show that at least one model of 386 CPU has a
previously undocumented errata in the "popal" instruction.
Specifically: when the stack-address size is 16 bits and the operand
size is 32 bits, the "popal" instruction will erroneously load the
high 16 bits of %esp from the value stored on the stack.
The "movl -20(%esp), %esp" instruction near the end of virt_call()
currently relies on the assumption that the high 16 bits of %esp will
already be zero, since they were set to zero by the "movzwl %bp, %esp"
instruction at the end of prot_to_real() and will not have been
subsequently modified by the "popal". This 386 CPU errata invalidates
that assumption, with the result that we end up loading the stack
pointer from an essentially undefined memory location.
Fix by inserting a "movzwl %sp, %esp" after the "popal" to explicitly
zero the high 16 bits of %esp.
Inserting this instruction also happens to work around another (known
and documented) errata in the 386, in which the CPU may malfunction if
"popal" is followed immediately by an instruction that uses a base
address register to form an effective address.
Debugged-by: Jaromir Capik <jaromir.capik@email.cz> Signed-off-by: Michael Brown <mcb30@ipxe.org>
Michael Brown [Mon, 9 Feb 2026 12:06:36 +0000 (12:06 +0000)]
[syslog] Allow port number to be specified for encrypted syslog server
The original implementation in commit 943b300 ("[syslog] Add basic
support for encrypted syslog via TLS") was based on examples found in
the rsyslog documentation rather than on RFC 5425, and unfortunately
used the default syslog port number 514 rather than the syslog-tls
port number 6514 defined in the RFC.
Extend parsing of the syslog server name to allow for an optional port
number (in the relatively intuitive format "server[:port]"). Retain
the existing (and incorrect) default port number to avoid breaking
backwards compatibility with existing setups.
Reported-by: Christian Nilsson <nikize@gmail.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
Michael Brown [Thu, 5 Feb 2026 13:26:42 +0000 (13:26 +0000)]
[loong64] Fix error identifier generation for LoongArch64
The initial code contribution from Loongson defined ASM_NO_PREFIX as
being "a" for this architecture. This seems to result in small values
such as error line numbers being rendered as "$r0, <value>" rather
than just "<value>".
This seems to hit an undocumented behaviour path in the GNU assembler.
For some reason ".long $r0" is not treated as a syntax error but will
instead be treated as a zero value. The net effect is therefore that
an extra zero value is emitted before the line number in the einfo
structure, which in turn causes the error information parser to see
all source code line numbers as zero. (The overall structure remains
valid since the length and all string offsets are encoded within the
structure itself, so nothing breaks when a spurious extra integer
field is appended.)
Fix by setting ASM_NO_PREFIX to the empty string (as for RISC-V),
since there are no literal value prefixes anyway in LoongArch64
assembly.
Michael Brown [Thu, 5 Feb 2026 11:58:01 +0000 (11:58 +0000)]
[pci] Ignore invalid subordinate bus numbers
Some systems (observed on a Dell C6615) fail to correctly populate the
subordinate PCI bus number on some PCI bridges. We do not currently
guard against this behaviour, causing us to subsequently scan through
a huge expanse of the PCI bus:dev.fn address range.
Fix by ignoring the subordinate bus number if it is lower than the
bridge's own bus number.
Reported-by: Anisse Astier <an.astier@criteo.com> Reported-by: Ahmad Mahagna <ahmhad@nvidia.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
Reduce the overhead of PCI configuration space accesses (and the
verbosity of debug messages) by caching the identified PCI root bridge
I/O protocol handle for the most recently accessed PCI device.
Michael Brown [Tue, 3 Feb 2026 19:02:51 +0000 (19:02 +0000)]
[ci] Run tests on pull requests
The automated tests that are run in the GitHub Actions workflow are
now as comprehensive as those that are run manually. Run tests on
pull requests as well as pushes, since the results are now
meaningfully informative.
Michael Brown [Tue, 3 Feb 2026 16:02:19 +0000 (16:02 +0000)]
[build] Mark MS-CHAPv2 as permitted for UEFI Secure Boot
MS-CHAPv2 and the underlying DES algorithm are cryptographically
obsolete, but still relatively widely used. There is no impact to
UEFI Secure Boot from using these obsolete algorithms: the only
untrusted inputs are the username, password, and received network
packets, and all of these are thoroughly validated before use.
Review these files and mark them as permitted for UEFI Secure Boot.
Michael Brown [Tue, 3 Feb 2026 10:16:14 +0000 (10:16 +0000)]
[build] Ensure dependencies of version.c are always rebuilt as expected
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>
[build] Exclude local named config headers from annotation checks
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>
Michael Brown [Fri, 30 Jan 2026 16:55:24 +0000 (16:55 +0000)]
[ci] Publish rolling release binaries via https://boot.ipxe.org
The boot.ipxe.org website is now hosted on GitHub Pages and built via
a GitHub Actions workflow. The rolling release binaries are fetched
from the build artifacts created by this repository.
Remove the rolling release tag mechanism, and instead trigger a
workflow run on the boot.ipxe.org repository to publish the updated
binaries.
Since filenames such as "ipxe.iso" may exist in each of several build
directories, we implement this as one release tag per build directory.
The GitHub Actions workflow automatically moves the tag to the most
recent commit and overwrites the existing release assets.
One downside of this is that running a local "git log" or similar may
show a large number of uninformative tags of the form "rolling/bin",
"rolling/bin-x86_64-efi", "rolling-arm64-efi", etc, all pointing at
the most recent commit. This clutter may be hidden using:
To avoid the unintentional creation of rolling release tags on forks,
we skip the whole publication job unless the environment variable
ROLLING_PREFIX is defined.
Michael Brown [Wed, 28 Jan 2026 19:44:09 +0000 (19:44 +0000)]
[build] Exclude external files from annotation checks
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.
Michael Brown [Wed, 28 Jan 2026 16:34:57 +0000 (16:34 +0000)]
[build] Mark compressed image tools as permitted for UEFI Secure Boot
Some older distributions (such as RHEL 8) provide their AArch64
kernels as gzip-compressed EFI binaries (with no self-decompressing
EFI stub present). We therefore enable support for gzip images by
default for arm64 EFI builds.
Review the files used to implement the gzip (and zlib) formats and
mark these as permitted for UEFI Secure Boot.
Michael Brown [Wed, 28 Jan 2026 16:12:40 +0000 (16:12 +0000)]
[build] Mark FDT management tools as permitted for UEFI Secure Boot
An EFI build of iPXE does not directly make use of a flattened device
tree (FDT) itself, but may pass on a device tree that the user chose
to download using the "fdt" command.
Review the simple files used to implement the "fdt" command and mark
these as permitted for UEFI Secure Boot.
Michael Brown [Wed, 28 Jan 2026 13:54:10 +0000 (13:54 +0000)]
[build] Mark dummy architecture headers as permitted for UEFI Secure Boot
The dummy header files in include/bits/*.h are placeholders for
architectures that do not need to define any architecture-specific
functionality in these areas. Mark these trivial files as permitted
for UEFI Secure Boot.
Michael Brown [Wed, 28 Jan 2026 13:31:07 +0000 (13:31 +0000)]
[build] Mark direct kernel loading as forbidden for UEFI Secure Boot
Our long-standing policy for EFI platforms is that we support invoking
binary executables only via the LoadImage() and StartImage() boot
services calls, so that all security policy decisions are delegated to
the platform firmware.
Most binary executable formats that we support are BIOS-only and
cannot in any case be linked in to an EFI executable. The only
cross-platform format is the generic Linux kernel image format as used
for RISC-V (and potentially also for AArch64).
Mark all files associated with direct loading of a kernel binary as
explicitly forbidden for UEFI Secure Boot.
Michael Brown [Wed, 28 Jan 2026 13:20:38 +0000 (13:20 +0000)]
[build] Mark GDB stub as forbidden for UEFI Secure Boot
Enabling the GDB debugger functionality would provide an immediate and
trivial Secure Boot exploit. Mark all GDB-related files as explicitly
forbidden for UEFI Secure Boot.
Michael Brown [Wed, 28 Jan 2026 13:04:07 +0000 (13:04 +0000)]
[build] Mark Realtek driver as permitted for UEFI Secure Boot
The Realtek driver and its dependencies are cleanly structured, easy
to review, directly maintained, and very well tested. Review these
files and mark them as permitted for UEFI Secure Boot.
Michael Brown [Wed, 28 Jan 2026 12:25:26 +0000 (12:25 +0000)]
[efi] Avoid dragging in IPv4, IPv6, and DNS support unconditionally
The efi_path_settings[] array includes symbol references to
&ip_setting, &ip6_setting, &dns_setting (and others) that currently
result in IPv4, IPv6, and DNS support being linked in even if disabled
in the build configuration.
Provide weak versions of these symbols to avoid the unconditional
inclusion of these features.
Reported-by: Pavitter Ghotra <pavitterghotra@yahoo.de> Signed-off-by: Michael Brown <mcb30@ipxe.org>
Michael Brown [Tue, 27 Jan 2026 16:39:40 +0000 (16:39 +0000)]
[build] Mark EFI SNP/MNP driver wrappers as permitted for UEFI Secure Boot
The EFI SNP/MNP driver wrapper is a trivial layer that exists only to
allow for the separation of "snponly.efi" as a build target. Review
this trivial wrapper and mark it as permitted for UEFI Secure Boot.
Michael Brown [Sat, 24 Jan 2026 09:57:42 +0000 (09:57 +0000)]
[ci] Use prebuilt containers to build and test iPXE
Use the prebuilt containers from https://github.com/ipxe/ipxe-builder
to build BIOS, SBI, UEFI, and Linux userspace versions of iPXE for all
supported CPU architectures, and to run the Linux userspace test suite
(via valgrind or qemu as applicable).
This reduces the time taken for GitHub CI runs by around 80%, while
increasing the build coverage to include RISC-V SBI, RISC-V UEFI, and
LoongArch64 UEFI, and increasing the test coverage to include running
the Linux userspace test suite on all supported CPU architectures.
Michael Brown [Sun, 25 Jan 2026 09:30:34 +0000 (09:30 +0000)]
[build] Allow GITVERSION to be specified as an environment variable
When using GitHub Actions with a job container that does not have the
git tools installed, the actions/checkout step will download a
snapshot instead of performing a git clone, and will therefore not
create a .git directory. Allow the GITVERSION variable to be
specified externally, so that the test suite logs can still display
the commit of the build being tested.
Michael Brown [Wed, 21 Jan 2026 23:19:36 +0000 (23:19 +0000)]
[build] Do not use "git log" to construct build timestamp
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.
Michael Brown [Wed, 21 Jan 2026 22:23:49 +0000 (22:23 +0000)]
[build] Do not use "git describe" to construct version number
Using "git describe" to automatically construct the version number has
caused more problems than it has solved. In particular, it causes
errors when building from a shallow clone of the repository, which is
a common scenario in modern automated build environments.
Define the base version number (currently 1.21.1+) as a set of
hardcoded constants within the Makefile, to be updated whenever a
release is made.
It is extremely useful to have the git commit ID present in the
startup banner. End users tend to provide screenshots of failures,
and having the commit ID printed at startup makes it trivial to
identify which version of the code is in use. Identify the git
version (if building from a git tree) by directly reading from
.git/HEAD and associated files. This allows the git commit ID to
potentially be included even if the build environment does not have
the git tools installed.
Use the default shallow clone in the GitHub Actions workflow, since we
no longer require access to the full commit history.
Michael Brown [Wed, 21 Jan 2026 12:55:12 +0000 (12:55 +0000)]
[build] Allow for per-architecture sysroots
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
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.
Michael Brown [Fri, 16 Jan 2026 22:38:07 +0000 (22:38 +0000)]
[build] Extend default configuration for non-BIOS builds
The current usage model for iPXE is that the default configuration is
relatively minimal to reduce code size, with users encouraged to build
from source if necessary to enable additional features. This approach
is somewhat incompatible with the Secure Boot model, which by design
makes it prohibitively difficult for users to use their own compiled
binaries. For published Secure Boot signed binaries to be useful,
they will have to already include all features that the majority of
users will need.
Extend the default configuration for EFI (and other non-BIOS
platforms) to include HTTPS support, framebuffer support, and a
selection of commands and features that are reasonably expected to be
used by large numbers of users.
The default configuration for BIOS platforms is deliberately left
unchanged, since BIOS binaries are typically subject to severe size
constraints.
Michael Brown [Fri, 16 Jan 2026 16:52:40 +0000 (16:52 +0000)]
[build] Canonicalise console type configuration
Move all console configuration from config/defaults/<platform>.h to
the top-level config/console.h, using indented conditional blocks to
clarify which console types are supported and enabled on each
platform.
Michael Brown [Fri, 16 Jan 2026 16:08:20 +0000 (16:08 +0000)]
[build] Canonicalise USB configuration
Move all USB configuration from config/defaults/<platform>.h to the
top-level config/usb.h, using indented conditional blocks to clarify
which options are supported and enabled on each platform.
Move all settings source selection from config/defaults/<platform>.h
to the top-level config/settings.h, using indented conditional blocks
to clarify which sources are supported and enabled on each platform.
Michael Brown [Fri, 16 Jan 2026 14:54:10 +0000 (14:54 +0000)]
[build] Sort general configuration in order of approachability
Reorder sections within config/general.h so that portions that are
easier to understand and more likely to be modified are towards the
top of the file, with more obscure and less frequently modified
options moved lower down.
Michael Brown [Fri, 16 Jan 2026 14:31:07 +0000 (14:31 +0000)]
[build] Canonicalise remaining portions of general configuration
Move remaining general configuration from config/defaults/<platform>.h
to the top-level config/general.h, using indented conditional blocks
to clarify which features are supported and enabled on each platform.
Michael Brown [Fri, 16 Jan 2026 14:02:35 +0000 (14:02 +0000)]
[build] Canonicalise SAN boot protocol configuration
Move all SAN boot protocol selection from config/defaults/<platform>.h
to the top-level config/general.h, using indented conditional blocks
to clarify which protocols are supported and enabled on each platform.
Move all download protocol selection from config/defaults/<platform>.h
to the top-level config/general.h, using indented conditional blocks
to clarify which protocols are supported and enabled on each platform.
Move all network protocol selection from config/defaults/<platform>.h
to the top-level config/general.h, using indented conditional blocks
to clarify which protocols are supported and enabled on each platform.
projects / thirdparty / ipxe.git / log
