Michael Brown [Thu, 9 Apr 2026 09:47:55 +0000 (10:47 +0100)]
[cloud] Update disk log console tool descriptions
Update the descriptive text for the disk log console tools to remove
references to INT13, since these now work for both BIOS and UEFI disk
log consoles.
Leave the script names as {aws,gce,ali}-int13con, to avoid breaking
any existing tooling that might use these names.
Michael Brown [Wed, 8 Apr 2026 12:55:47 +0000 (13:55 +0100)]
[cloud] Fix architecture detection for partitioned disk images
Allow the UEFI CPU architecture to be detected for the partitioned
disk images generated by genfsimg as of commit 2c84b68 ("[build] Use a
partition table in generated USB disk images").
Michael Brown [Sun, 29 Mar 2026 12:37:55 +0000 (13:37 +0100)]
[disklog] Generalise CONSOLE_INT13 to CONSOLE_DISKLOG
The name "int13" is intrinsically specific to a BIOS environment.
Generalise the build configuration option CONSOLE_INT13 to
CONSOLE_DISKLOG, in preparation for adding EFI disk log console
support.
Existing configurations using CONSOLE_INT13 will continue to work.
Michael Brown [Mon, 6 Apr 2026 23:37:00 +0000 (00:37 +0100)]
[undi] Pad transmit buffer length to work around vendor driver bugs
The workaround used for UEFI in commit 926816c ("[efi] Pad transmit
buffer length to work around vendor driver bugs") is also applicable
to the BIOS UNDI driver.
Apply the same workaround of padding the transmit I/O buffers to the
minimum Ethernet frame length before passing them to the underlying
UNDI driver's transmit function.
Reported-by: Alexander Patrakov <patrakov@gmail.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
Michael Brown [Mon, 6 Apr 2026 21:24:08 +0000 (22:24 +0100)]
[efi] Remove the Dhcp6Dxe driver veto
Commit cb95b5b ("[efi] Veto the Dhcp6Dxe driver on all platforms")
vetoed the Dhcp6Dxe driver to work around the bug described at
https://github.com/tianocore/edk2/issues/10506 that results in
EfiDhcp6Stop() getting stuck in a tight loop waiting for an event that
will never occur.
Since we now call UnloadImage() at TPL_APPLICATION, we no longer
trigger the bug in Dhcp6Dxe, and so the veto may be removed.
Michael Brown [Mon, 6 Apr 2026 21:17:58 +0000 (22:17 +0100)]
[efi] Drop to external TPL when unloading vetoed images
As of commit c3376f8 ("[efi] Drop to external TPL for calls to
ConnectController()"), the veto mechanism will drop to TPL_APPLICATION
for calls to DisconnectController().
Match this behaviour for calls to UnloadImage(), since that is likely
to result in calls to DisconnectController(). For example, any EDK2
driver using NetLibDefaultUnload() as its unload handler will call
DisconnectController() to disconnect itself from all handles.
On Ubuntu/Debian, syslinux-common installs mbr.bin to
/usr/lib/syslinux/mbr/mbr.bin. This path is not currently searched by
find_syslinux_file(), causing USB disk image generation to fail with
"could not find mbr.bin".
Add /usr/lib/syslinux/mbr, /usr/share/syslinux/mbr, and
/usr/local/share/syslinux/mbr to the search paths.
Michael Brown [Thu, 26 Mar 2026 14:46:26 +0000 (14:46 +0000)]
[build] Allow binaries to request a log partition from genfsimg
For UEFI, the USB disk image is constructed from the built EFI binary
(e.g. bin-x86_64-efi/ipxe.efi) by genfsimg, which does not itself have
any way to access the build configuration. We therefore need a way to
annotate the binary such that genfsimg can determine whether or not to
include a log partition within the USB disk image.
The "OEM ID" and "OEM information" fields within the PE header can be
used for this, since they are easily accessed and serve no other
purpose. We define bit 0 of "OEM information" as a flag indicating
that a log partition should be included. If this bit is set, genfsimg
will create a log partition with a layout matching that of the BIOS
build (i.e. using partition 3 and at an offset of 16kB from the start
of the disk).
The PE header is constructed by elf2efi.c, which takes as an input the
linked ELF form of the binary. We use an ELF .note section to allow
any linked-in object to communicate the log partition request through
to elf2efi.c, which then populates the OEM information field
accordingly.
We choose to use the same field locations within the BIOS bzImage
header, since this allows genfsimg to use the same logic for both BIOS
and UEFI binaries. In a BIOS build, there is no external processing
equivalent to elf2efi.c, and so we construct the field value directly
using absolute symbols and explicit relocation records.
(Note that the bzImage header is relevant only when using genfsimg to
construct a combined BIOS/UEFI image. In the common case of building
a BIOS-only image such as bin/ipxe.usb, the partition table is
manually constructed by usbdisk.S and genfsimg is not involved.)
Michael Brown [Thu, 26 Mar 2026 12:51:20 +0000 (12:51 +0000)]
[build] Work around syslinux bugs in FAT cluster counting
The syslinux function check_fat_bootsect() performs some sanity checks
to ensure that the filesystem type string (e.g. "FAT12") is correct
for the total number of clusters in the FAT. There is unfortunately a
bug in its calculation of the number of sectors occupied by the root
directory, which causes it to underestimate the number of sectors by a
factor of 32.
When the total number of clusters is close to the FAT12 limit of 4096,
this bug can cause syslinux to erroneously report that the filesystem
has "more than 4084 clusters but claims FAT12".
Work around this bug by selecting an explicit cluster size in order to
avoid potentially problematic cluster counts. We default to using 4kB
clusters, doubling to 8kB if using 4kB would result in a total cluster
count near 4096 (the FAT12 limit) or near 65536 (the FAT16 limit).
Michael Brown [Thu, 26 Mar 2026 12:40:40 +0000 (12:40 +0000)]
[build] Use sector count values consistently in genfsimg
The calculations around the FAT filesystem layout currently use a
mixture of kilobytes and sector counts. Switch to using sector counts
throughout the calculation, to make the code easier to read.
Michael Brown [Mon, 23 Mar 2026 16:08:09 +0000 (16:08 +0000)]
[build] Use a partition table in generated USB disk images
The USB disk image constructed by util/genfsimg is currently a raw FAT
filesystem, with no containing partition. This makes it incompatible
with the use of CONSOLE_INT13, since there is no way to add a
dedicated log partition without a partition table.
Add a partition table when building a non-ISO image, using the mbr.bin
provided by syslinux (since we are already using syslinux to invoke
the ipxe.lkrn within the FAT filesystem).
The BIOS .usb targets are built using a manually constructed partition
table with C/H/S geometry x/64/32. Match this geometry to minimise
the differences between genfsimg and non-genfsimg USB disk images.
Michael Brown [Tue, 24 Mar 2026 16:41:30 +0000 (16:41 +0000)]
[build] Ensure that generated filesystem images retain no stale content
We use mformat to ensure that the FAT filesystem starts as empty.
However, formatting the filesystem can still leave old data blocks
present (though unreferenced) within the disk image.
Truncate the image to a zero length before extending, to ensure that
no stale content is retained.
Michael Brown [Fri, 20 Mar 2026 13:48:54 +0000 (13:48 +0000)]
[cloud] Add utility to read INT13CON partition in Alibaba Cloud
Following the examples of aws-int13con and gce-int13con, add a utility
that can be used to read the INT13 console log from a used iPXE boot
disk in Alibaba Cloud Elastic Compute Service (ECS).
We cannot reliably access the used iPXE boot disk (or a snapshot
created from it) since OSS buckets in mainland China cannot be
accessed due to Chinese laws. We therefore create a snapshot and
attach this snapshot as a data disk to a temporary Linux instance, as
we do in Google Compute Engine.
Unlike in Google Compute Engine, we cannot reliably capture serial
port output from the temporary Linux instance. Issuing the relevant
GetInstanceConsoleOutput API call will cause the output to be captured
once and (unpredictably) cached. Without knowing in advance precisely
when the output is complete, we cannot use this approach to capture
the relevant part of the output.
We therefore use an Alibaba Cloud Linux image that includes the Cloud
Assistant Agent. This allows us to use the RunCommand API call to run
a command on the instance and capture the output, all done via the
control plane so that we are not dependent on having direct network
access to the temporary instance.
Joseph Wong [Thu, 19 Mar 2026 13:08:55 +0000 (13:08 +0000)]
[bnxt] Update conditions for invoking short commands
Include additional condition to invoke short command logic when
firmware indicates it is required. Replace 100ms delay with wmb() to
ensure DMA buffer is ready when short command is invoked.
Signed-off-by: Joseph Wong <joseph.wong@broadcom.com>
Michael Brown [Wed, 18 Mar 2026 16:01:54 +0000 (16:01 +0000)]
[cloud] Add utility for importing images to Alibaba Cloud
Following the examples of aws-import and gce-import, add a utility
that can be used to upload an iPXE disk image to Alibaba Cloud Elastic
Compute Service (ECS) as a bootable image.
The iPXE disk image is first uploaded to a temporary Object Storage
Service (OSS) bucket and then imported as an ECS image. The temporary
bucket is deleted after use.
As with Google Compute Engine, an appropriate image family name is
identified automatically: "ipxe" for BIOS images, "ipxe-uefi-x86-64"
for x86_64 UEFI images, and "ipxe-uefi-arm64" for AArch64 UEFI images.
This allows the latest image within each family to be launched within
needing to know the precise image name.
Copies of the images are uploaded to all selected regions. One major
complication is that OSS buckets in mainland China can be created but
cannot be accessed due to Chinese laws, which require an ICP filing
for any bucket hosted in mainland China. We work around this
restriction by first uploading the image to a region outside mainland
China and then using a temporary Function Compute function running in
each region to copy the images to the OSS bucket via the internal OSS
endpoints, which are not subject to the same restrictions.
Michael Brown [Wed, 18 Mar 2026 15:12:11 +0000 (15:12 +0000)]
[undi] Drag in PCI-specific configuration
The undionly.kpxe binary does not need the full PCI bus support.
However, the overwhelming majority of UNDI devices are PCI-based and
we already end up dragging in PCI configuration space support in order
to be able to test for devices with broken interrupts.
Dragging in the PCI configuration allows the PCI settings mechanism to
also be present, which is often useful for end users. The total cost
is around 200 bytes in the final binary, which is acceptable for a
generally very useful feature.
Users wanting to minimise the binary size can choose to explicitly
disable PCI_SETTINGS via config/settings.h.
Michael Brown [Fri, 13 Mar 2026 15:40:27 +0000 (15:40 +0000)]
[efi] Add a dummy SBOM PE section
Since October 2025, the Microsoft UEFI Signing Requirements have
included a clause stating that "submissions must contain a valid
signed SPDX SBOM in a custom '.sbom' PE section". A list of required
fields is provided, and a link is given to "the Microsoft SBOM tool to
aid SBOM generation". So far, so promising.
The Microsoft SBOM tool has no support for handling a .sbom PE
section. There is no published document that specifies what is
supposed to appear within this PE section. An educated guess is that
it should probably contain the raw JSON data in the same format that
the Microsoft SBOM tool produces.
The list of required fields does not map to identifiable fields within
the JSON. In particular:
- "file name / software"
This might be the top-level "name" field. It's hard to tell. The
SPDX SBOM specification is not particularly informative either: the
only definition it appears to give for "name" is "This field
identifies the name of an Element as designated by the creator",
which is a spectacularly useless definition.
- "software version / component generation (shim)"
This may refer to the "packages[].versionInfo" field. There is no
obvious relevance for the words "component", "generation", or
"shim". The proximity of "generation" and "shim" suggests that this
might be related in some way to the SBAT security generation, which
is absolutely not the same thing as the software version.
- "vendor / company name (this must exactly match the verified company
name in the submitter's EV certificate on the Microsoft HDC partner
center account)"
This is clearly written as though it has some significance for the
UEFI signing submission process. Unfortunately there is no obvious
map to any defined SBOM field. An educated guess is that this might
be referring to "packages[].supplier", since experiments show that
the Microsoft SBOM tool will fail validation unless this field is
present.
- "product-name"
This might also be the top-level "name" field. There is no
indication given as to how this might differ from "file name /
software".
- "OEM Name" and "OEM ID"
These seem to be terms made up on the spur of the moment. The
three-letter sequence "OEM" does not appear anywhere within the
codebase of the Microsoft SBOM tool.
In the absence of any meaningful specification, we choose not to
engage in good faith with this requirement. Instead, we construct a
best guess at the contents of a .sbom section that has some chance of
being accepted by the UEFI signing submission process. We assume that
anything that passes "sbom-tool validate" will probably be accepted,
with the only actual check being that the supplier name must match the
registered EV code signing certificate.
To anyone who actually cares about the arguably valuable benefits of
having a software bill of materials: please stop creating junk
requirements. If you want people to actually make the effort to
produce useful SBOM data, then make it clear what data you want.
Provide unambiguous specifications. Provide example files. Provide
tools that actually do the job they are claimed to do. Don't just
throw out another piece of "MUST HAS THING BECAUSE IS MORE SECURITY"
garbage and call it a day.
Michael Brown [Tue, 10 Mar 2026 13:41:48 +0000 (13:41 +0000)]
[ci] Add a workflow to import images to Google Cloud
Add a workflow to build and import the official iPXE images for Google
Cloud. As with the AWS import, treat this as a workflow that must be
triggered manually.
Michael Brown [Tue, 10 Mar 2026 12:34:10 +0000 (12:34 +0000)]
[cloud] Specify Google Cloud project explicitly for storage client
The storage client is currently constructed with the project inferred
from the environment, rather than using the project specified via the
command line arguments.
Fix by passing the project name to the storage client constructor.
Michael Brown [Mon, 9 Mar 2026 22:52:38 +0000 (22:52 +0000)]
[test] Assign unique MAC addresses for test network devices
Commit 19dffdc ("[efi] Allow for creating devices with no EFI parent
device") relaxed the restriction on attempting to create SNP devices
when no EFI parent device is available, with the result that the test
network devices created when running the IPv4 tests are now registered
as SNP devices.
Since the dummy EFI parent device path is fixed and the test network
device MAC addresses are empty, the SNP devices end up with identical
constructed device paths and registration of the second and subsequent
devices will fail since device paths must be unique.
Fix by assigning MAC addresses to the test network devices.
Reported-by: Miao Wang <shankerwangmiao@gmail.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
Michael Brown [Sat, 7 Mar 2026 23:32:03 +0000 (23:32 +0000)]
[ci] Add a workflow to import images to AWS EC2
Add a workflow to build and import the official iPXE images for AWS
EC2. Treat this as a workflow that must be triggered manually, since
importing is prone to failure for reasons unrelated to the state of
the codebase (e.g. the creation of new regions, or an explosion at a
data centre) and so should not result in CI failures being reported
against specific commits.
Michael Brown [Thu, 5 Mar 2026 15:56:07 +0000 (15:56 +0000)]
[efi] Do not unconditionally raise back to internal TPL
Most TPL manipulation is handled by efi_raise_tpl()/efi_restore_tpl()
pairs. The exceptions are the places where we need to temporarily
drop to a lower TPL in order to allow a timer interrupt to occur.
These currently assume that they are called only from code that is
already running at the internal TPL (generally TPL_CALLBACK). This
assumption is not always correct. In particular, the call from
_efi_start() to efi_driver_reconnect_all() takes place after the SNP
devices have been released and so will be running at the external TPL.
Create an efi_drop_tpl()/efi_undrop_tpl() pair to abstract away the
temporary lowering of the TPL, and ensure that the TPL is always
raised back to its original level rather than being unconditionally
raised to the internal TPL.
Michael Brown [Thu, 5 Mar 2026 12:24:35 +0000 (12:24 +0000)]
[efi] Allow creating an image device handle with no parent device
When we fall back to using our own loaded image's device handle
(instead of the most recently opened SNP device handle), we may find
that the device handle is no longer valid since we have disconnected
the driver that originally provided it.
Check for existence of the device path protocol on the identified
parent handle, and choose not to attempt to set a parent-child
relationship if the parent handle appears to no longer be valid.
Michael Brown [Thu, 5 Mar 2026 12:10:15 +0000 (12:10 +0000)]
[efi] Install protocols onto a dedicated device handle
When we fall back to using our own loaded image's device handle
(instead of the most recently opened SNP device handle), we may find
that some protocols (e.g. EFI_SIMPLE_FILE_SYSTEM_PROTOCOL) are already
present on this handle.
Fix by creating a child device handle with an added Uri() device path
component, and installing EFI_SIMPLE_FILE_SYSTEM_PROTOCOL and others
onto this handle instead of onto the identified parent device handle.
This also provides a way for us to communicate the image URI to a
chainloaded iPXE, so that that iPXE can set its current working URI
appropriately.
A side effect of this change is that the EFI_SIMPLE_NETWORK_PROTOCOL
will be found on the parent of the loaded image's device handle,
rather than directly on the loaded image's device handle. This will
not cause problems for a chainloaded iPXE, since that will already use
LocateDevicePath() to find EFI_SIMPLE_NETWORK_PROTOCOL (or the
EFI_MANAGED_NETWORK_SERVICE_BINDING_PROTOCOL created by MnpDxe) and so
will already find the instance on the parent device handle. If other
UEFI executables are found to exist that do require the protocols to
be installed directly on the loaded image's device handle, then we
could potentially install copies of these protocol instances on the
device handle.
Michael Brown [Thu, 5 Mar 2026 11:29:41 +0000 (11:29 +0000)]
[efi] Allow executing images even with no open network devices
We need a device handle from which to nominally load an EFI image. We
currently rely on using the most recently opened network device's SNP
device handle, in the same way that we use the most recently opened
network device when loading a BIOS PXE NBP image. If there is no most
recently opened network device, then we cannot execute an EFI image.
We use three aspects of the SNP device handle: the handle itself
(giving us something on which to install protocols), the associated
device path (giving us a base path from which to construct the new
image's file path), and the associated network device (giving us an
interface for the PXE base code protocol installation).
Make the network device optional by simply choosing not to install the
PXE base code protocols when no network device is defined. This
allows us to fall back to using our own loaded image's device handle
and device path for the other two purposes.
Michael Brown [Thu, 5 Mar 2026 12:55:37 +0000 (12:55 +0000)]
[efi] Try all supported autoexec protocols
When chainloaded from another iPXE, there will be both a virtual
filesystem and a managed network protocol available through which we
could attempt to load autoexec.ipxe.
Try both of these, with the virtual filesystem attempted first so that
an autoexec.ipxe that was explicitly downloaded by the chainloading
iPXE will have the highest priority.
Michael Brown [Thu, 5 Mar 2026 12:37:00 +0000 (12:37 +0000)]
[efi] Treat a URI device path as higher priority than a cached DHCP packet
We currently expect to find either a cached DHCP packet (from a UEFI
PXE boot) or a URI device path (from a UEFI HTTP boot), but not both
simultaneously. When both are present, the cached DHCP packet will
currently override any current working URI that was previously derived
from a URI device path.
Treat the URI device path as being more informative than the cached
DHCP packet by swapping the order in which these are processed.
Leave the boot option device path as being a lower priority than a
cached DHCP packet, since the boot option device path may well refer
to an earlier boot stage.
Michael Brown [Tue, 3 Mar 2026 14:57:17 +0000 (14:57 +0000)]
[github] Add organization to sponsorship links
There is no viable way to link to the list of sponsorship recipients.
Add the organization itself as a sponsorship recipient, solely in
order to enable the use of https://github.com/sponsors/ipxe as a
central link for sponsorship information.
Michael Brown [Tue, 3 Mar 2026 11:04:18 +0000 (11:04 +0000)]
[cachedhcp] Set current working URI to cached DHCP filename
For a UEFI HTTP boot, we set the current working URI based on the
loaded image device path. The autoexec.ipxe script will be fetched
from the same directory as the iPXE binary itself.
For a BIOS or UEFI PXE boot, we do not explicitly set a current
working URI, but rely on the fact that registering the cached DHCP
settings block will cause the TFTP code to set the current working URI
to "tftp://${next-server}/". The autoexec.ipxe script will therefore
be fetched from the default directory (which is most probably the root
directory) of the TFTP server.
When using a UEFI shim, the shim will always fetch iPXE from the same
directory as the shim itself. This leads to a somewhat unintuitive
requirement for a UEFI PXE boot: the shim and iPXE must be placed in
the same directory, but the corresponding autoexec.ipxe script must be
placed in the root directory.
As with the loaded image device path for a UEFI HTTP boot, the
existence of a cached DHCP packet gives us a way to construct the URI
of our own binary. We can therefore choose to use this to set the
current working URI, so that the autoexec.ipxe script may be placed in
the same directory as the iPXE binary itself. This is the least
surprising location, and avoids the need for lengthy explanations in
documentation.
Choose to set the current working URI at the point that the cached
DHCP packet is recorded, rather than the point at which it is applied
and registered as a settings block. This avoids some awkward corner
cases (such as failing to find a matching network device for the
DHCPACK), and naturally ensures that we retrieve the next-server
address and filename from the same DHCP packet. We rely on the order
in which cached DHCP packets are recorded to impose a priority
ordering: later packets (e.g. PxeBSACK) will override earlier ones.
To avoid breaking existing setups that do place the autoexec.ipxe
script in the root directory, we modify the fetching logic to first
attempt to retrieve autoexec.ipxe from the current working URI, then
from the root directory of that URI.
As with commit a69afd7 ("[tftp] Use TFTP server URI only if no other
working URI is set"), this is technically a breaking change in
behaviour, but the new behaviour is almost certainly less surprising
than the existing behaviour. Scripts that rely on the current working
URI being set to the root of the TFTP server can use absolute URIs
(i.e. add an initial slash): this is more explicit and will work on
iPXE builds both before and after this change.
Michael Brown [Mon, 2 Mar 2026 16:10:49 +0000 (16:10 +0000)]
[build] Add support for including a UEFI shim in filesystem images
Add support for loading iPXE via a UEFI shim in ISO and USB images.
Since the iPXE shim's default loader filename is currently "ipxe.efi"
for all CPU architectures, at most one architecture within an image
may use a shim. (This limitation should be removed in the next signed
release of the iPXE shim.)
Michael Brown [Mon, 2 Mar 2026 00:08:18 +0000 (00:08 +0000)]
[efi] Automatically open network device matching loaded image device path
It is unintuitive to have to include an "ifopen" at the start of an
autoexec.ipxe script. Commit efe8126 ("[cachedhcp] Automatically open
network device matching cached DHCPACK") causes the chainloaded device
to be opened automatically, using the cached DHCPACK to identify the
chainloaded device.
In the case of a UEFI HTTP(S) boot, the firmware does not provide
access to the DHCPACK and we are forced to instead extract the very
limited amount of information encoded into the loaded image's device
path.
Mark the device matching the loaded image's device path to be opened
automatically, so that the chainloaded device will be opened in the
same way for both TFTP and HTTP(S) boots.
Michael Brown [Sun, 1 Mar 2026 16:37:29 +0000 (16:37 +0000)]
[tftp] Use TFTP server URI only if no other working URI is set
We currently set the working URI to "tftp://${next-server}/" whenever
the value of the next-server setting changes.
Many years ago this was required for the default boot sequence, which
would treat the boot filename as a potentially relative URI. Since
commit 481a217 ("[autoboot] Retain initial-slash (if present) when
constructing TFTP URIs"), the default boot sequence has always
constructed an absolute URI.
There is still a valid use case for setting the default working URI
based on the value of next-server: it allows command sequences such as
dhcp && chain ${filename}
or
set next-server 192.168.0.1
chain myscript.ipxe
to work as expected. Note that since "${filename}" may be a relative
path, it is necessary for the current working URI to be the root of
the TFTP server, i.e. "tftp://${next-server}/", rather than the full
path "tftp://${next-server}/${filename}".
In the case of a UEFI HTTP(S) boot, we already have a working URI set
on entry (to be the URI of the iPXE binary itself). Running "dhcp"
would change this current working URI, which is quite unintuitive.
Similarly, once we start executing an image (e.g. a script), the
current working URI is set to the image's own URI, so that relative
URIs may be used in a script to download files relative to the
location of the script itself. Running "dhcp" within the script may
or may not change the current working URI: it will happen to do so
only if the TFTP server address happens to change. This is also
somewhat unintuitive.
Change the behaviour of the TFTP settings applicator to treat the TFTP
server URI as a fallback, to be used only if nothing else has already
set a current working URI. This is technically a breaking change in
behaviour, but the new behaviour is almost certainly much less
surprising than the existing behaviour. (Scripts that do genuinely
expect to acquire a new TFTP server address can use full URIs of the
form "tftp://${next-server}/...": this is more explicit and will work
on iPXE builds both before and after this change.)
Michael Brown [Fri, 27 Feb 2026 13:16:51 +0000 (13:16 +0000)]
[tls] Respond to received closure alerts
TLS defines a mechanism for gracefully closing a connection via a
closure alert. We currently ignore this alert since it is a warning
rather than an error, and warnings are allowed to be ignored.
In almost all cases, a higher-level protocol such as HTTP will already
give us the information required to know when the connection should be
closed. In the very rare case of an HTTPS server that does not send a
Content-Length header and does not close the TCP connection, only the
closure alert indicates that the whole file has been retrieved.
Handle a received closure alert by gracefully closing the connection.
Reported-by: Tuomo Tanskanen <tuomo.tanskanen@est.tech> Signed-off-by: Michael Brown <mcb30@ipxe.org>
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.
projects / thirdparty / ipxe.git / log
