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.
Michael Brown [Fri, 16 Jan 2026 12:05:38 +0000 (12:05 +0000)]
[build] Canonicalise command list configuration
Move all command selection from config/defaults/<platform>.h to the
top-level config/general.h, using indented conditional blocks to
clarify which commands are supported and enabled on each platform.
Michael Brown [Thu, 15 Jan 2026 16:14:19 +0000 (16:14 +0000)]
[build] Canonicalise image type configuration
Move all image type selection from config/defaults/<platform>.h to the
top-level config/general.h, using indented conditional blocks to
clarify which image types are supported and enabled on each platform.
Michael Brown [Wed, 14 Jan 2026 22:37:05 +0000 (22:37 +0000)]
[build] Mark more reviewed files as permitted for UEFI Secure Boot
Mark dynamic keyboard map support and the "pciscan", "usbscan", and
"time" commands as permitted for UEFI Secure Boot, on the basis that
these features have previously been present in binaries signed by
Microsoft.
Michael Brown [Wed, 14 Jan 2026 15:51:07 +0000 (15:51 +0000)]
[build] Mark MD4 and MD5 as forbidden for UEFI Secure Boot
A past security review identified MD4 and MD5 support as features that
ought to be disabled by default. (There is zero impact on UEFI Secure
Boot itself from having these algorithms enabled: this was just a side
comment in the review.)
As noted in the resulting commit 7f2006a ("[crypto] Disable MD5 as an
OID-identifiable algorithm by default"), the actual MD5 code will
almost certainly still be present in the binary due to its implicit
use by various features. Disabling MD5 support via config/crypto.h
simply removes the OID-identified algorithm, which prevents it from
being used as an explicitly identified algorithm (e.g. in an X.509
certificate digest).
Match the intent of this review comment by marking the OID-identified
algorithms for MD4 and MD5 as forbidden for UEFI Secure Boot.
Extend this to also disable the "md4sum" command and the use of the
md5WithRSAEncryption OID-identified algorithm. (The "md5sum" command
is left enabled for historical reasons, and we have no definition for
md4WithRSAEncryption anyway.)
Michael Brown [Wed, 14 Jan 2026 14:36:49 +0000 (14:36 +0000)]
[build] Mark known reviewed files as permitted for UEFI Secure Boot
Some past security reviews carried out for UEFI Secure Boot signing
submissions have covered specific drivers or functional areas of iPXE.
Mark all of the files comprising these areas as permitted for UEFI
Secure Boot.
Michael Brown [Wed, 14 Jan 2026 13:25:34 +0000 (13:25 +0000)]
[build] Mark core files as permitted for UEFI Secure Boot
Mark all files used in a standard build of bin-x86_64-efi/snponly.efi
as permitted for UEFI Secure Boot. These files represent the core
functionality of iPXE that is guaranteed to have been included in
every binary that was previously subject to a security review and
signed by Microsoft. It is therefore legitimate to assume that at
least these files have already been reviewed to the required standard
multiple times.
Michael Brown [Wed, 14 Jan 2026 13:20:11 +0000 (13:20 +0000)]
[build] Check for standalone FILE_LICENCE() and FILE_SECBOOT() declarations
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.
Michael Brown [Tue, 13 Jan 2026 14:38:37 +0000 (14:38 +0000)]
[build] Mark existing files as explicitly forbidden for Secure Boot
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.
Michael Brown [Tue, 13 Jan 2026 13:49:27 +0000 (13:49 +0000)]
[build] Define a mechanism for marking Secure Boot permissibility
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.
Michael Brown [Fri, 9 Jan 2026 18:29:53 +0000 (18:29 +0000)]
[neighbour] Treat delayed transmissions as pending operations
Treat each delayed transmission as a pending operation, so that the
"sync" command can be used to ensure that all delayed packets have
been transmitted.
Michael Brown [Fri, 9 Jan 2026 16:36:52 +0000 (16:36 +0000)]
[tcp] Report TCP statistics via the "ipstat" command
Gather some basic statistics on TCP connections to allow out-of-order
packets and duplicate packets to be observed even in non-debug builds.
Report these statistics via the existing "ipstat" command, rather than
introducing a separate "tcpstat" command, on the basis that we do not
need the additional overhead of a separate command.
Michael Brown [Fri, 9 Jan 2026 14:40:31 +0000 (14:40 +0000)]
[malloc] Increase heap size to 4MB
Commit 2d180ce ("[tcp] Update maximum window size to 2MB") increased
the TCP window size to avoid filling the TCP window on typical modern
links.
The total heap size is only 512kB. Given that RX I/O buffers are
typically subject to alignment constraints, it is plausible that we
may be able to actually buffer only 256kB of data before having to
discard queued out-of-order packets.
On a low latency network, this behaviour is not a problem: the sender
will rapidly retransmit the lost or discarded packets. On a high
latency network, the sender's congestion control algorithm will end up
calculating a congestion window that is substantially smaller than our
advertised 2MB, which will result in a drastic reduction in actual
throughput.
We do not want to increase the heap size arbitrarily, since we still
have the constraint that memory used by iPXE may be permanently lost
to the operating system (depending on how the operating system is
booted). However, the cost of keeping the heap size down to 512kB is
no longer acceptable given that large downloads over high-speed
wide-area networks are now routine.
Increase the heap size from 512kB to 4MB. This should be sufficient
to hold an entire 2MB TCP window for a single connection under most
sensible conditions. For example:
The notable exception is that of a network where jumbo frames are in
use, but the TCP connection ends up using a standard 1460-byte MSS.
If this is found to be an issue in practice, then one possible
solution would be to shrink (or reallocate) I/O buffers for
out-of-order queued data.
Experimentation shows that before this change, an induced latency of
25ms (representative of a typical connection to a public cloud
provider) would cause the download speed to vary unpredictably between
2MB/s and 25MB/s. After this change, the speed in this test scenario
remains consistently high at 25MB/s.
Michael Brown [Fri, 9 Jan 2026 13:18:20 +0000 (13:18 +0000)]
[tcp] Discard packets that lie immediately before the receive window
We will currently enqueue (rather than discard) retransmitted packets
that lie immediately before the current receive window. These packets
will be harmlessly discarded when the receive queue is processed
immediately afterwards, but cause confusion when attempting to debug
TCP performance issues.
Fix by adjusting the comparison so that packets that lie immediately
before the receive window will be discarded immediately and never
enqueued.
Michael Brown [Tue, 6 Jan 2026 14:04:00 +0000 (14:04 +0000)]
[neighbour] Add the ability to artificially delay outbound packets
Add a fault-injection mechanism that allows an arbitrary delay
(configured via config/fault.h) to be added to any packets transmitted
via the neighbour resolution mechanism, as a way of reproducing
symptoms that occur only on high-latency connections such as a
satellite uplink.
The neighbour discovery mechanism is not a natural conceptual fit for
this artficial delay, since neighbour discovery has nothing to do with
transmit latency. However, the neighbour discovery mechanism happens
to already include a deferred transmission queue that can be (ab)used
to implement this artifical delay in a minimally intrusive way. In
particular, there is zero code size impact on a standard build with no
artificial delay configured.
Implementing the delay only for packets transmitted via neighbour
resolution has the side effect that broadcast packets (such as DHCP
and ARP) are unaffected. This is likely in practice to produce a
better emulation of a high-latency uplink scenario, where local
network traffic such as DHCP and ARP will complete quickly and only
the subsequent TCP/UDP traffic will experience delays.
Michael Brown [Mon, 5 Jan 2026 15:53:20 +0000 (15:53 +0000)]
[neighbour] Split out deferred transmission from discovery completion
Split out the logic for transmitting any deferred packets as a
separate function, as a precursor to supporting the ability to add
deliberate latency to transmitted packets.
Michael Brown [Mon, 5 Jan 2026 15:46:52 +0000 (15:46 +0000)]
[neighbour] Use discovery protocol field to identify incomplete neighbours
Use the discovery protocol pointer field (rather than the running
state of the discovery timer) to determine whether or not neighbour
discovery is ongoing, as a precursor to allowing the timer to be
(ab)used for adding deliberate latency to transmitted packets.
Michael Brown [Mon, 5 Jan 2026 14:22:16 +0000 (14:22 +0000)]
[neighbour] Always use network device's own link-layer address
The API for neighbour_tx() allows for an explicit source link-layer
address, but this will be ignored if the packet is deferred for
transmission after completion of neighbour discovery. The network
device's own link-layer address will always be used when sending
neighbour discovery packets, and when sending any deferred packets
after discovery completes.
All callers pass in the network device's own link-layer address as the
source address anyway, and so this explicit source link-layer address
is never used for any meaningful purpose.
Simplify the neighbour_tx() API by removing the ability to pass in an
explicit source link-layer address.
Michael Brown [Mon, 29 Dec 2025 14:01:46 +0000 (14:01 +0000)]
[crypto] Allow for zero-length big integer literals
Ensure that zero-length big integer literals are treated as containing
a zero value. Avoid tests on every big integer arithmetic operation
by ensuring that bigint_required_size() always returns a non-zero
value: the zero-length tests can therefore be restricted to only
bigint_init() and bigint_done().
Michael Brown [Fri, 19 Dec 2025 15:24:47 +0000 (15:24 +0000)]
[crypto] Allow ecPublicKey to be identified as a public-key algorithm
Add a public-key algorithm to the definition of the "ecPublicKey"
OID-identified algorithm, and move this definition to ecdsa.c to avoid
unconditionally dragging in ECDSA support.
Michael Brown [Fri, 19 Dec 2025 14:24:27 +0000 (14:24 +0000)]
[test] Ensure OID-identified algorithms are present for X.509 tests
The algorithms required for the X.509 tests are accessed indirectly
via their OID-identified algorithms, rather than directly via symbols.
Ensure that the required OID-identified algorithm definitions are
included regardless of the configuration in config/crypto.h.
Michael Brown [Thu, 18 Dec 2025 23:10:57 +0000 (23:10 +0000)]
[test] Test verification of constructed signature
Some signature schemes (such as ECDSA) allow for non-deterministic
signatures. Provide more information in test results by performing
verification of the constructed signature even when it does not match
the expected test case result: this allows us to distinguish between a
bug that is generating invalid signatures and a bug that is generating
valid but non-canonical signatures.
Michael Brown [Thu, 18 Dec 2025 15:38:11 +0000 (15:38 +0000)]
[crypto] Allow for an explicit representation of point at infinity
ECDSA requires the ability to add two arbitrary curve points, either
of which may legitimately be the point at infinity.
Update the API so that curves must choose an explicit affine
representation for the point at infinity, and provide a method to test
for this representation. Multiplication and addition will now allow
this representation to be provided as an input, and will not fail if
the result is the point at infinity. Callers must explicitly check
for the point at infinity where needed (e.g. after computing the ECDHE
shared secret curve point).
Michael Brown [Wed, 17 Dec 2025 20:35:18 +0000 (20:35 +0000)]
[test] Test signature verification independently of signing
Copy and modify the signature defined within the test case for
verification tests, rather than relying on the modifiable signature
constructed by the signing portion of the same test.
Michael Brown [Thu, 11 Dec 2025 14:04:10 +0000 (14:04 +0000)]
[efi] Retry calls to GetRNG() as needed
The UEFI specification allows GetRNG() to return EFI_NOT_READY, which
is not a particularly helpful error status since there is nothing that
can sensibly be done except to retry immediately.
Retry failed calls to GetRNG() up to a maximum number of attempts.
Debugged-by: Stoo Davies <sdavies@nvidia.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
Michael Brown [Thu, 11 Dec 2025 15:02:28 +0000 (15:02 +0000)]
[crypto] Generalise rsa_parse_integer() to asn1_enter_unsigned()
ECDSA signature values and private keys are fixed-length unsigned
integers modulo N (the group order of the elliptic curve) and are
therefore most naturally represented in ASN.1 using ASN1_OCTET_STRING.
Private key representations do use ASN1_OCTET_STRING, but signature
values tend to use ASN1_INTEGER, which adds no value but does ensure
that the encoding becomes variable-length and requires handling a
pointless extra zero byte if the MSB of the unsigned value happens to
be set.
RSA also makes use of ASN1_INTEGER for modulus and exponent values.
Generalise the existing rsa_parse_integer() to asn1_enter_unsigned()
to allow this code to be reused for ECDSA.
Michael Brown [Sat, 6 Dec 2025 16:59:29 +0000 (16:59 +0000)]
[crypto] Allow for addition of arbitrary Weierstrass curve points
ECDSA verification requires the ability to add two arbitrary curve
points (as well as the ability to multiply a curve point by a scalar).
Add an elliptic curve method to perform arbitrary point addition.
Pass in curve points as affine coordinates: this will require some
redundant conversions between affine coorfinates and the internal
representation as projective coordinates in Montgomery form, but keeps
the API as simple as possible. Since we do not expect to perform a
high volume of ECDSA signature verifications, these redundant
calculations are an acceptable cost for keeping the code simple.
Michael Brown [Fri, 5 Dec 2025 16:08:49 +0000 (16:08 +0000)]
[crypto] Split out Weierstrass point initialisation and finalisation
Prepare for adding an operation to add arbitrary curve points by
splitting out initialisation and finalisation from the multiplication
operation.
Pass explicit temporary buffer pointers to weierstrass_init() and
weierstrass_done(), to ensure that stack consumption does not increase
as a result of splitting out this functionality.
Michael Brown [Fri, 5 Dec 2025 14:50:57 +0000 (14:50 +0000)]
[crypto] Verify that weierstrass_multiply() result is not point at infinity
The point at infinity cannot be represented in affine coordinates, and
so cannot be returned as a valid result from weierstrass_multiply().
The implementation uses projective coordinates internally, in which a
point at infinity is represented by a zero Z-coordinate. Treat a zero
Z-coordinate as an invalid result.
The projective coordinates are calculated modulo 4N, and so a zero
value may be represented as 0, N, 2N, or 3N. To minimise code size,
defer the test until after inverting the Z co-ordinate via Fermat's
little theorem via bigint_mod_exp_ladder() (which will calculate the
inverse of zero as zero, and will always produce a result strictly
modulo N).
Defer the test further until after converting the result back to
affine coordinates, to allow the debug message showing the
multiplication result to be printed.
Michael Brown [Fri, 5 Dec 2025 13:00:12 +0000 (13:00 +0000)]
[crypto] Expose the base point as an explicit elliptic curve property
Add the generator base point as an explicit property of an elliptic
curve, and remove the ability to pass a NULL to elliptic_multiply() to
imply the use of the generator base point.
Michael Brown [Thu, 4 Dec 2025 13:52:08 +0000 (13:52 +0000)]
[http] Abort connections after a long period of inactivity
Once an HTTP download has started (i.e. once all request headers have
been sent), we generally have no more data to transmit. If an HTTP
connection dies silently (e.g. due to a network failure, a NIC driver
bug, or a server crash) then there is no mechanism that will currently
detect this situation by default.
We do send TCP keep-alives (to maintain state in intermediate routers
and firewalls), but we do not attempt to elicit a response from the
server. RFC 9293 explicitly states that the absence of a response to
a TCP keep-alive probe must not be interpreted as indicating a dead
connection, since TCP cannot guarantee reliable delivery of packets
that do not advance the sequence number.
Scripts may use the "--timeout" option to impose an overall time limit
on downloads, but this mechanism is off by default and requires
additional thought and configuration by the user (which goes against
iPXE's general philosophy of being as automatic as possible).
Add an idle connection watchdog timer which will cause the HTTP
download to abort after 120 seconds of inactivity. Activity is
defined as an I/O buffer being delivered to the HTTP transaction's
upstream data transfer interface.
Downloads over HTTPS may experience a substantial delay until the
first recorded activity, since all TLS negotiation (including
cross-chained certificate downloads and OCSP checks) must complete
before any application data can be sent. We choose to not reset the
watchdog timer during TLS negotiation, on the basis that 120 seconds
is already an unreasonably long time for a TLS negotiation to take to
complete. If necessary, resetting the watchdog timer could be
accomplished by having the TLS layer deliver zero-length I/O buffers
(via xfer_seek()) to indicate forward progress being made.
When using PeerDist content encoding, the downloaded content
information is not passed through to the content-decoded interface and
so will not be classed as activity. Any activity in the individual
PeerDist block downloads (either from peers or as range requests from
the origin server) will be classed as activity in the overall
download, since individual block downloads do not buffer data but
instead pass it through directly via the PeerDist download
multiplexer.
Michael Brown [Thu, 27 Nov 2025 16:39:52 +0000 (16:39 +0000)]
[crypto] Allow for OID-identified elliptic curve algorithms
Elliptic curves in X.509 certificates are identified via the
id-ecPublicKey object identifier (1.2.840.10045.2.1), with the
specific elliptic curve identified via a second OID in the algorithm
parameters.
Michael Brown [Tue, 2 Dec 2025 13:13:01 +0000 (13:13 +0000)]
[crypto] Remove obsolete maximum output length method
Now that public-key algorithms use ASN.1 builders to dynamically
allocate the output data, there is no further need for callers to be
able to determine the maximum output length.
Michael Brown [Fri, 28 Nov 2025 13:21:00 +0000 (13:21 +0000)]
[crypto] Restructure handling of ASN.1 bit strings
Signature values in ASN.1 tend to be encoded as bit strings rather
than octet strings. In practice, no existent signature scheme uses a
non-integral number of bytes.
Switch to using a standard ASN.1 cursor to hold signature values, to
simplify consuming code. Restructure the API to treat entering an
ASN.1 bit string in the same way as entering any other ASN.1 type.
Michael Brown [Tue, 25 Nov 2025 11:59:03 +0000 (11:59 +0000)]
[efi] Allow for creating devices with no EFI parent device
On some systems (observed on an AWS m8g.medium instance in eu-west-2),
the UEFI firmware fails to enumerate some of the underlying hardware
devices. On these systems, we cannot comply with the UEFI device
model by adding our SNP device as a child of the hardware device and
appending to the parent hardware device path, since no parent hardware
device has been created.
Work around these systems by allowing for the creation of SNP devices
with no parent device.
Michael Brown [Mon, 24 Nov 2025 20:27:53 +0000 (20:27 +0000)]
[pci] Use runtime selectable PCI I/O API for EFI cloud builds
On some systems (observed on an AWS m8g.medium instance in eu-west-2),
the UEFI firmware omits the PCI host bridge drivers for all but the
first PCI bus. The observable result is that any devices on other PCI
buses (such as the ENA network device) are not enumerated by the UEFI
firmware and are therefore unusable by iPXE.
Support these systems by switching to using PCIAPI_CLOUD for EFI cloud
builds, trying the EFI PCI I/O API first and falling back to direct
access (via ECAM) for devices that the UEFI firmware has failed to
enumerate itself.
Michael Brown [Mon, 24 Nov 2025 14:44:53 +0000 (14:44 +0000)]
[pci] Allow PCI configuration space access mechanism to vary by range
On some systems (observed on an AWS EC2 c7a.medium instance in
eu-west-2), there is no single PCI configuration space access
mechanism that covers all PCI devices. For example: the ECAM may
provide access only to bus 01 and above, with type 1 accesses required
to access bus 00.
Allow the choice of PCI configuration space access mechanism to be
made on a per-range basis, rather than being made just once in an
initialisation function.
Michael Brown [Wed, 19 Nov 2025 22:17:14 +0000 (22:17 +0000)]
[arm] Avoid unaligned accesses for memcpy() and memset()
iPXE runs only in environments that support unaligned accesses to RAM.
However, memcpy() and memset() are also used to write to graphical
framebuffer memory, which may support only aligned accesses on some
CPU architectures such as ARM.
Restructure the 64-bit ARM memcpy() and memset() routines along the
lines of the RISC-V implementations, which split the region into
pre-aligned, aligned, and post-aligned sections.
Michael Brown [Tue, 11 Nov 2025 16:12:26 +0000 (16:12 +0000)]
[efi] Mark Ip4Config.h as a non-imported header
The Ip4Config.h header has been removed from the EDK2 codebase as
obsolete. However, we may still encounter it in the wild and so it is
useful to retain the GUID and the corresponding protocol name for
debug messages.
Add an iPXE include guard to this file so that the EDK2 header import
script will no longer attempt to import it from the EDK2 tree.
Michael Brown [Tue, 11 Nov 2025 16:09:27 +0000 (16:09 +0000)]
[efi] Mark UgaDraw.h as a non-imported header
The UgaDraw.h header has been removed from the EDK2 codebase as
obsolete. However, we may still encounter it in the wild and so it is
useful to retain the GUID and the corresponding protocol name for
debug messages.
Add an iPXE include guard to this file so that the EDK2 header import
script will no longer attempt to import it from the EDK2 tree.
projects / thirdparty / ipxe.git / log
