Michael Brown [Tue, 21 Jul 2026 12:28:23 +0000 (13:28 +0100)]
[dns] Pass a non-null peer socket address to xfer_open_socket()
Commit 3662065 ("[dns] Use all configured DNS servers") changed the
logic from opening a single defined nameserver address to opening an
unspecified peer socket address and then specifying the full peer
address for each transmitted packet.
The peer socket address was left unspecified by passing a null pointer
to xfer_open_socket(). This is supported by the UDP socket opener,
but technically violates the internal API (which allows the local
socket address to be a null pointer, but not the peer socket address).
In particular, in a debug build using DEBUG=open, the debug code will
itself dereference the peer address pointer.
Fix by embedding the name server socket address within the DNS request
structure, and passing this to xfer_open_socket().
Michael Brown [Tue, 21 Jul 2026 11:34:16 +0000 (12:34 +0100)]
[xfer] Do not attempt to find an opener for a null URI scheme
With no current working URI, even a fully resolved URI may not have a
scheme. Attempting to open such a URI will currently result in
xfer_uri_opener() calling strcasecmp() with a null pointer. On a
system that guards against null pointer dereferences, this will result
in a segfault (or the equivalent, such as a Synchronous Exception on
arm64 UEFI).
Fix by checking that the URI is absolute (i.e. has a scheme) before
calling xfer_uri_opener(), as is already done elsewhere.
Reported-by: Matt Fleming <matt@readmodwrite.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
Michael Brown [Sun, 19 Jul 2026 14:08:57 +0000 (15:08 +0100)]
[tls] Parse ServerKeyExchange record immediately
As of commit 433a8f5 ("[tls] Retain a reference in the key schedule to
the bound identity"), the act of binding the server identity is
logically separated from the act of validating the server identity.
We may therefore bind the server identity (by verifying the signature
over the Diffie-Hellman parameters) and agree the ephemeral shared
secret immediately upon receiving the ServerKeyExchange record, rather
than deferring the verification until we have a validated identity.
This provides a closer match to the flow required for TLS version 1.3,
where the ephemeral shared secret is used for all messages after
ServerHello, and so must always be agreed prior to validation.
Michael Brown [Fri, 17 Jul 2026 10:55:04 +0000 (11:55 +0100)]
[image] Allow download progress messages to be silenced
Add a "--quiet" option to each image-acquiring command that currently
accepts a "--timeout" option, to allow the displaying of the download
URI and the progress dots to be inhibited.
This is particularly useful with "data:" URIs to inhibit the echoing
of the full data URI contents:
iPXE> imgfetch -n hw data:,hello%20world
data:,hello%20world... ok
iPXE>
The recorded console output may be cleared if necessary by clearing
the setting:
clear builtin/dmesg
The name ${dmesg} is chosen as being unlikely to collide with any
existing variables used in end-user scripts. A separate "dmesg"
command is not provided, but could easily be added if useful.
Note that iPXE supports recursive variable expansion in shell
commands. Typing an interactive command such as "echo ${dmesg}" or
"param dmesg ${dmesg}" is therefore a great way to exercise the memory
allocator to the point of exhaustion. Use "show -q dmesg" to show the
ring buffer contents.
Michael Brown [Wed, 15 Jul 2026 22:28:38 +0000 (23:28 +0100)]
[blob] Add an abstraction of an openable data blob
Within the iPXE data transfer interface model, openers are fully
asynchronous and may not deliver any data until after the opener has
returned.
Provide a trivial openable data blob object (as a generalisation of
the "hello world" data transfer interface example code) that will
simply deliver a single fixed blob of data to its parent interface and
then close itself.
Michael Brown [Tue, 14 Jul 2026 11:45:32 +0000 (12:45 +0100)]
[cmdline] Add "imgset" command
A commonly requested feature is to allow a setting to be populated
with the contents of an HTTP response. This currently requires a
somewhat ugly workaround of having the HTTP endpoint generate an iPXE
executable script fragment that includes the "#!ipxe" shebang and the
relevant "set" command.
For HTTP endpoints that are under the end user's control, this
workaround is viable (though still ugly). For HTTP endpoints that are
outside the user's control (such as the AWS metadata endpoints), this
workaround cannot be used.
Add an "imgset" command that can be used to store downloaded content
directly into a setting.
Michael Brown [Mon, 13 Jul 2026 14:39:00 +0000 (15:39 +0100)]
[http] Allow issuing requests with an explicitly specified HTTP method
The design of IMDSv2 within both AWS and Alibaba Cloud requires the
client to obtain a temporary token via an HTTP PUT request. There is
no authentication on this request and there is no associated request
body: the requirement to use PUT exists solely to reduce the attack
surface for SSRF attacks (since vulnerable servers are much more
likely to be able to be tricked into issuing a GET request than a PUT
request).
iPXE can currently issue requests using HTTP GET (if the request body
is empty) or HTTP POST (if the request body includes form parameters).
There is no support for issuing a PUT request, or for allowing a
script to explicitly specify the HTTP method.
Add a "--method" option to the "params" command to allow an arbitrary
request method name to be specified, and use this as the HTTP request
method.
Michael Brown [Mon, 13 Jul 2026 14:32:43 +0000 (15:32 +0100)]
[params] Avoid calling strcmp() with a NULL parameter list name
If a named parameter block is created and then a URI is parsed that
attempts to use a nonexistent unnamed parameter block (or vice versa),
then the code in find_parameters() will currently call strcmp() with a
NULL argument, resulting in a read-only access to undefined memory.
Michael Brown [Mon, 13 Jul 2026 10:51:14 +0000 (11:51 +0100)]
[mime] Add support for MIME multipart images
Some public clouds (such as AWS and Alibaba Cloud) allow for only a
single user metadata blob. The official iPXE cloud images will
attempt to download and boot from this user metadata, expecting it to
contain an iPXE script.
This works, but causes conflicts when another consumer (such as
cloud-init) also wants to use the same metadata blob. There are
workarounds (such as publishing the cloud-init script at an
alternative URI outside of the instance metadata service, and using
the iPXE script to direct cloud-init to use the alternative URI via
kernel command-line arguments), but these are cumbersome and may
weaken security since the alternative URI cannot provide the same
level of guaranteed access restrictions.
There is support within cloud-init for parsing a multipart MIME
archive, which may contain additional shell scripts, JSON data, etc,
alongside the cloud-init configuration itself. This is the standard
and documented method that cloud-init has chosen to solve the issue of
obtaining multiple data sources from a single user metadata blob.
Add support for multipart MIME as an archive image format from which
iPXE will extract the first body part that has the "text/x-ipxe" MIME
type. This allows the iPXE boot script to be placed alongside
cloud-init configuration within a single user metadata blob.
Michael Brown [Fri, 10 Jul 2026 15:29:52 +0000 (16:29 +0100)]
[hermon] Add missing write barrier after initiating reset
Ensure that the reset register write does not get reordered behind the
first PCI configuration space read that checks to see if the reset has
completed.
Debugged-by: Jaroslav Svoboda <multi.flexi@seznam.cz> Tested-by: Jaroslav Svoboda <multi.flexi@seznam.cz> Signed-off-by: Michael Brown <mcb30@ipxe.org>
Michael Brown [Fri, 10 Jul 2026 11:35:27 +0000 (12:35 +0100)]
[image] Make text-based image data usable by string functions
Using standard string functions for parsing text-based image formats
is currently cumbersome since there is no guaranteed NUL terminator,
and so code must laboriously keep track of the remaining image length
and use only those string functions that accept a length limit.
Ensure that the byte immediately following the image data is always a
NUL, thereby allowing all string functions to be used when parsing
images. Provide a "const char *text" pointer aliased to the image
data, to make it explicit that image data may always be treated as a
NUL-terminated string.
Michael Brown [Fri, 10 Jul 2026 14:19:44 +0000 (15:19 +0100)]
[xferbuf] Provide an image-backed data transfer buffer
Define and use a data transfer buffer that is directly backed by an
image, rather than downloading into a umalloc()-based data transfer
buffer and then transferring ownership to the image.
Michael Brown [Wed, 8 Jul 2026 22:27:05 +0000 (23:27 +0100)]
[tls] Retain a reference in the key schedule to the bound identity
Change the "bound" field from being a boolean flag to being a
reference to the server identity (i.e. the certificate) to which the
shared secret has been bound.
This reduces the chances for future bugs that could be caused by
potentially losing track of which identity has been bound, and also
provides a natural way to extend the field to be able to represent an
identity that has not yet been validated (as will be required for TLS
version 1.3 key exchange).
Add a check that the bound identity has been validated at the point of
sending our client Finished handshake. We must defer sending the
client Finished until validation has completed, to prevent the server
from sending application traffic until we are ready to receive it, and
so this provides a natural point at which we know that the bound
identity must have been validated.
Since the validity check is now deferred until the point of sending
the client Finished, and since commit 6ba010e ("[tls] Reject incorrect
server names before completing validation") already ensures that the
certificate must have the correct name, there is no need to extract
and store the certificate's public key separately after validation has
completed.
We also update the session key (and related parameters) only if the
bound identity has been validated. This creates an invariant that if
a server certificate is stored in the session then it is always
guaranteed to be valid, which simplifies reasoning about session
resumption flows.
Michael Brown [Wed, 8 Jul 2026 13:44:55 +0000 (14:44 +0100)]
[tls] Reject incorrect server names before completing validation
We currently verify the certificate name only after completing
validation of the certificate chain. Perform this check instead at
the point of parsing the Certificate record, to create an invariant
that the recorded server certificate always has the correct name (even
if not yet validated).
Michael Brown [Wed, 8 Jul 2026 10:50:20 +0000 (11:50 +0100)]
[tls] Guard against resuming from an empty resumption master secret
There should be no circumstance that leads to a session being resumed
without having a valid session resumption secret that was stored by a
successfully established previous connection.
As an additional layer of defence in depth, clear the "keyed" and
"bound" flags in the key schedule if it is ever resumed from an empty
session resumption secret.
Michael Brown [Wed, 8 Jul 2026 11:02:51 +0000 (12:02 +0100)]
[tls] Poison initial resumption master secret
There should be no circumstance that leads to a session being resumed
without having a valid session resumption secret that was stored by a
successfully established previous connection.
As an additional layer of defence in depth, poison the initial session
resumption master secret so that a predictable all-zero secret can
never be used accidentally in future.
Michael Brown [Wed, 8 Jul 2026 10:14:50 +0000 (11:14 +0100)]
[tls] Poison initial key derivation function master secret
A freshly initialised key derivation function master secret has the
"keyed" flag clear and so cannot accidentally be used to establish a
full TLS connection.
As an additional layer of defence in depth, poison the initial key
derivation master secret so that a predictable all-zero secret can
never be used accidentally in future.
Michael Brown [Tue, 7 Jul 2026 14:19:02 +0000 (15:19 +0100)]
[tls] Track and check key schedule state
TLS already allows for several different paths to the establishment of
a shared secret channel. The shared secret may be generated by the
client and encrypted using RSA key transport, or negotiated as a
Diffie-Hellman shared secret (via FFDHE or ECDHE), or mutually agreed
to be restored from a previously saved session resumption secret.
TLS version 1.3 defines several new paths to exist alongside these:
ephemeral key exchange is moved to the ClientHello and ServerHello
messages, server identity is verified using a CertificateVerify
message (instead of a signed ServerKeyExchange or an encrypted
ClientKeyExchange), and session resumption is handled via a new
pre-shared key mechanism.
While TLS version 1.3 in isolation is substantially simpler and
cleaner than earlier versions, the requirement to support both new and
old versions in the same code comes with a significant complexity
cost.
Guard against the possibility of future bugs by defining two
properties for the key schedule:
- a "keyed" flag indicating that the key schedule actually holds some
shared secret key material (e.g. from ECDHE)
- a "bound" flag indicating that the shared secret key material in the
key schedule has been bound to the identity represented by the
server's certificate
These flags are updated when relevant key schedule events happen, and
validated before processing the server's Finished message. If we
somehow end up receiving a Finished message without having established
and authenticated a shared secret, this check prevents us from marking
the connection as ready for application data.
Michael Brown [Mon, 6 Jul 2026 12:43:05 +0000 (13:43 +0100)]
[tls] Guard against a premature server Finished
A malicious server that immediately sends a Finished record (without
ever having sent a ServerHello) will currently cause tls_prf() to get
stuck in an infinite loop attempting to generate pseudorandom data
using the null digest algorithm.
Fix by checking that the key schedule digest size is non-zero
(i.e. that the digest is not the null digest) before attempting to
process the Finished record.
Michael Brown [Mon, 6 Jul 2026 11:14:34 +0000 (12:14 +0100)]
[tls] Send closure alert only when we are initiating the closure
When the TLS connection is closed by the underlying socket, the
closure alert will not be able to be sent. This currently results in
a harmless but mildly irritating error message when debugging is
enabled.
Fix by sending the closure alert only when we are actively choosing to
close the connection.
Michael Brown [Mon, 6 Jul 2026 10:38:55 +0000 (11:38 +0100)]
[tls] Handle key exchange within key schedule
Ephemeral key exchange is currently handled as part of sending the
ClientKeyExchange handshake record, with almost entirely separate
implementations for DHE and ECDHE.
Create wrappers around the underlying key exchange algorithm to handle
the TLS-specific aspects (such as padding and stripping leading zeros
for DHE), and use these for both DHE and ECDHE key exchange.
Michael Brown [Fri, 3 Jul 2026 15:48:10 +0000 (16:48 +0100)]
[cloud] Use "param" command to provide Google metadata request header
Requests for metadata within Google Compute Engine require a custom
HTTP header "Metadata-Flavor: Google" to guard against Server-Side
Request Forgery (SSRF) attacks.
Support for this was originally implemented in 2017 using a custom
HTTP request header generator that added this header to any requests
made to metadata.google.com.
In commit 96bb6ba ("[params] Allow for arbitrary HTTP request headers
to be specified"), iPXE gained the ability to generate arbitrary HTTP
headers via the "param" command.
Remove the custom HTTP request header generator, enable the "param"
command for cloud builds, and update the embedded script for Google
Compute Engine to construct the required Metadata-Flavor header.
Michael Brown [Fri, 3 Jul 2026 13:00:09 +0000 (14:00 +0100)]
[tls] Restructure to use a single key derivation function master secret
Calls to the key derivation function tls_prf() currently have to pass
the relevant secret (i.e. the pre-master secret or the master secret)
as a parameter.
Restructure to more closely match the design of the TLS version 1.3
key schedule, which maintains a single running secret (which we choose
to name the "key derivation function master secret") that is always
implicitly used as the secret for key expansion.
The secret value is currently used by tls_prf() only as the key to
hmac_init(). We can therefore use hmac_key() to reduce the secret to
a fixed-length value. (The TLS master secret is already a fixed 48
bytes, but the pre-master secret may be any length.)
The fixed length of the secret is dependent upon the protocol version
and the cipher suite digest algorithm. For TLS version 1.2, the
length is the HMAC key size for the digest algorithm. For TLS version
1.1, which uses separate invocations of HMAC-MD5 and HMAC-SHA1, the
length is the sum of the HMAC-MD5 and HMAC-SHA1 key sizes. (For TLS
version 1.3, the length will be the HKDF key size, i.e. the output
size of the digest algorithm.)
To avoid introducing some very messy memory allocation code paths, we
continue to use a fixed size of 48 bytes for the resumption master
secret stored in the TLS session. This is sufficient to hold the
48-byte raw master secret for TLS version 1.2 and earlier, and will
also be sufficient to hold the HKDF Derive-Secret output for the
longest supported digest algorithm (SHA-384) in TLS version 1.3.
Michael Brown [Thu, 2 Jul 2026 14:09:28 +0000 (15:09 +0100)]
[tls] Treat session secret as "resumption master secret"
When resuming a session in TLS versions 1.2 and earlier, the master
secret is simply reused. The value stored in the session is therefore
the same as the master secret used in the connection.
For TLS version 1.3, there is a separate concept of a "resumption
master secret" that is derived from the original connection's master
secret, and from which the resumed connection's new master secret will
be derived.
Rename the session master_secret to resumption_master_secret to
clarify this separation.
Resume use of the master secret (i.e. copy the secret from the session
to the connection) only after the cipher suite has been selected, to
reduce differences with the expected flow for TLS version 1.3.
Michael Brown [Thu, 2 Jul 2026 12:09:44 +0000 (13:09 +0100)]
[virtio] Allow for long delays in processing transmit queue submissions
When using QEMU with the KVM accelerator, MMIO writes to the queue
doorbell register are likely to hit an ioeventfd region. KVM will
signal readiness on the ioeventfd file descriptor (which will
eventually wake up the QEMU userspace process to handle the MMIO
write) and then immediately resume execution of the iPXE guest.
This can result in high latencies in processing submitted descriptors.
With the small transmit queue fill level used by iPXE, this can easily
overrun the transmit queue and result in large numbers of dropped
transmissions.
Increase the transmit queue fill level to utilise the whole queue if
needed, and use the transmission deferral mechanism to avoid dropping
packets when high latencies occur during operation.
Michael Brown [Thu, 2 Jul 2026 12:00:28 +0000 (13:00 +0100)]
[virtio] Fix queue size calculations
The queue size calculations currently do not take into account the
fact that each packet requires a pair of descriptors. If the device
happens to present an extremely small queue (16 descriptors for Q0, 32
descriptors for Q1) then this will result in the driver submitting
descriptors beyond the queue's descriptor count. This does not result
in any invalid memory accesses (since the descriptor ring length is
rounded up to a 4kB boundary), but does result in an unusable network
device.
Fix by scaling the packet count and descriptor count values as
required.
Michael Brown [Tue, 30 Jun 2026 12:15:24 +0000 (13:15 +0100)]
[tls] Move handshake digest within the scope of the key schedule
The digest algorithm selected by the cipher suite is used for both
calculating the handshake digest and as the tls_prf() key derivation
function digest algorithm. (In TLS version 1.3, it will similarly be
used as the HKDF digest algorithm.)
Move the digest algorithm selection within the key schedule, to
clarify that the scope of this digest algorithm is wider than solely
being used to calculate the handshake digest.
Michael Brown [Tue, 30 Jun 2026 12:13:04 +0000 (13:13 +0100)]
[tls] Clarify TLS key schedule function names
The term "key" has a large number of uses in the context of TLS.
Reduce opportunities for confusion by renaming tls_key_init() and
tls_key_reset() to less generic names.
Michael Brown [Tue, 30 Jun 2026 13:58:33 +0000 (14:58 +0100)]
[crypto] Define a structure for holding hybrid MD5+SHA1 HMAC keys
The hybrid PRF used in TLS version 1.1 and earlier does not use HMAC
with the hybrid MD5+SHA1 algorithm: it uses separate invocations of
HMAC-MD5 and HMAC-SHA1.
Using hmac_keysize(&md5_sha1_algorithm) would produce a size too small
to hold the combined HMAC-MD5 and HMAC-SHA1 keys. One option would be
to set the (currently unused) MD5+SHA1 block size to 128, thereby
ensuring that hmac_keysize() would happen to return a length large
enough to hold both HMAC keys. This would avoid the need to
special-case the MD5+SHA1 algorithm when calculating the required HMAC
key size for the PRF, but would inevitably cause confusion in future.
Set the MD5+SHA1 block size to 64 (since both algorithms have the same
underlying block size, and this would therefore produce the "correct"
result if anything were ever to use HMAC directly with the hybrid
MD5+SHA1 algorithm), and define a separate structure for holding the
separated HMAC keys used by the PRF in TLS version 1.1 and earlier.
Michael Brown [Thu, 2 Jul 2026 10:39:31 +0000 (11:39 +0100)]
[crypto] Make maximum TLS version a configurable option
The minimum supported TLS version is already configurable via
TLS_VERSION_MIN in config/crypto.h, but changing the maximum TLS
version currently requires editing the source code proper. This makes
it cumbersome to test older TLS versions, and therefore increases the
chances that support for older versions will end up breaking as new
features are added.
Move TLS_VERSION_MAX from include/ipxe/tls.h to config/crypto.h to
ease the process of testing older TLS versions.
Michael Brown [Thu, 2 Jul 2026 10:19:40 +0000 (11:19 +0100)]
[crypto] Re-add missing digestInfo prefix for MD5+SHA1
Commit efa9515 ("[tls] Split out hybrid MD5+SHA1 algorithm used in TLS
version 1.1") accidentally removed the empty RSA digestInfo prefix
required for verifying DHE and ECDHE ServerKeyExchange messages when
using TLS version 1.1. (Non-ephemeral cipher suites using RSA key
transport would still work, since the digestInfo is required only for
signatures, not for encryption/decryption.)
Fix by restoring the dummy digestInfo prefix for MD5+SHA1.
Michael Brown [Tue, 30 Jun 2026 09:38:37 +0000 (10:38 +0100)]
[build] Use dynamic keyboard map by default in UEFI builds
As described in commit 05cb930 ("[build] Extend default configuration
for non-BIOS builds"), the default configuration for EFI needs to
allow for the unfortunate fact that users will not be able to rebuild
the Secure Boot binaries for themselves.
The keyboard map currently defaults to "us" (i.e. no keyboard
remapping) on all platforms. Switch to using the "dynamic" keyboard
map by default for EFI platforms.
Do not use the "dynamic" keyboard map by default on Linux platforms
(where the input character read by iPXE has already passed through the
host's keyboard mapping) or on RISC-V SBI (where input is expected to
come via a serial port rather than a directly attached keyboard).
Requested-by: Simon Fonteneau <blog@lesfourmisduweb.org> Signed-off-by: Michael Brown <mcb30@ipxe.org>
Michael Brown [Mon, 29 Jun 2026 15:37:53 +0000 (16:37 +0100)]
[crypto] Allow for the construction of fixed-size HMAC keys
An HMAC key can always be reduced to the block size of the underlying
digest algorithm. Provide hmac_key() that can be used to perform this
reduction, and hmac_init_key() as a way to initialise an HMAC digest
operation from a previously reduced key.
Michael Brown [Mon, 29 Jun 2026 11:37:08 +0000 (12:37 +0100)]
[s390x] Add time source based on the architectural Time-of-Day clock
The S/390 architecture provides instructions to read the Time-of-Day
(TOD) clock, which increments at a well-defined rate regardless of the
underlying physical clock speed, and has an epoch that starts from
zero at the beginning of the 20th century.
Use this clock to provide both interval timing (i.e. udelay() and
currticks()) and the wall-clock time source. For short interval
timing, we choose to save on code size by treating one millisecond as
1024 microseconds.
Michael Brown [Sun, 28 Jun 2026 19:06:46 +0000 (20:06 +0100)]
[s390x] Add support for the PRNO TRNG as an entropy source
The "prno" instruction available on newer CPUs provides a hardware
True Random Number Generator (TRNG) that can be used as an entropy
source, similar to the x86 "rdrand" instruction.
Michael Brown [Thu, 25 Jun 2026 12:44:08 +0000 (13:44 +0100)]
[crypto] Remove redundant DHE algorithm
Remove the now-unused implementation of DHE that requires explicit
group parameters, since we now use a standalone key exchange algorithm
abstraction instead.
Michael Brown [Thu, 25 Jun 2026 11:37:24 +0000 (12:37 +0100)]
[crypto] Allocate FFDHE temporary space on demand
Now that key exchange algorithms are allowed to fail to construct a
shared public key, we can allocate the temporary working space for
FFDHE calculations on demand rather than using a static buffer.
Michael Brown [Thu, 25 Jun 2026 11:03:54 +0000 (12:03 +0100)]
[crypto] Correct maximum length of FFDHE prime modulus
Commit 70d63be ("[crypto] Add RFC 3526 FFDHE key exchange algorithms")
defined FFDHE_LEN as a fixed value (rather than deriving it from the
stored length of the Euler constant) and accidentally expressed it as
a bit length rather than a byte length, resulting in substantial
amounts of wasted space.
Fix the maximum length of the modulus and add static assertions to
ensure that the two constants are exactly the required size for this
length.
Michael Brown [Tue, 23 Jun 2026 11:46:55 +0000 (12:46 +0100)]
[crypto] Generalise implementation of Merkle-Damgård hash algorithms
All of our current digest algorithms (MD4, MD5, SHA-1, and the SHA-2
family) use a Merkle-Damgård construction, with only the compression
function, the initial digest values, the field sizes, and the
endianness differing between algorithms.
Provide a common implementation for Merkle-Damgård hash algorithms to
reduce code size. Values are now held as host-endian quantities, with
any swapping performed byte-by-byte as data is accumulated (using a
compile-time constant that is XORed with the byte index).
For the SHA family of algorithms, the values w[] are now calculated
iteratively as we progress through the main loop: this substantially
reduces the stack space required for the compression function.
Animesh Bhatt [Mon, 22 Jun 2026 09:18:28 +0000 (14:48 +0530)]
[aqc1xx] Free outstanding receive I/O buffers on close
atl_close() freed the descriptor rings but left the posted receive I/O
buffers allocated, leaking them and tripping an assertion on the next
open. Free any outstanding receive I/O buffers in atl_close().
Animesh Bhatt [Mon, 22 Jun 2026 09:12:08 +0000 (14:42 +0530)]
[aqc1xx] Set netdev->dma for operation with an IOMMU
On AQC113 adapters with an IOMMU (e.g. Intel VT-d) enabled, no packets
are received and DHCP fails: the driver never set netdev->dma, leaving
the transmit buffers unmapped for DMA. This worked without an IOMMU
because the physical address equals the device address, but with an
IOMMU the unmapped DMA access faults and stalls the receive path. Set
netdev->dma and a 64-bit DMA mask so that transmit buffers are mapped
through the firmware IOMMU, as done by the other iPXE drivers.
Michael Brown [Fri, 19 Jun 2026 17:09:56 +0000 (18:09 +0100)]
[tls] Centralise pseudorandom data generation
TLS version 1.3 has a formal key schedule based on HKDF, and requires
the client to be able to recall ephemeral secrets at multiple points
within the connection lifecycle. For example: the ephemeral private
key for X25519 key exchange may be required when constructing
ClientHello (for a TLS version 1.3 key share) or when constructing
ClientKeyExchange (if subsequently falling back to use TLS version
1.2), and again when parsing a ServerHello key share or a
ServerKeyExchange.
Some ephemeral private keys may be large (e.g. for ffdhe4096). Avoid
the need to store these large (and variably sized) private keys by
instead instantiating a standalone HKDF instance that we seed with
per-connection random data and subsequently use to generate ephemeral
private keys on demand. (Note that this instance is unrelated to the
HKDF instance defined in the formal key schedule for TLS: we are
choosing to reuse HKDF for this purpose simply because supporting TLS
version 1.3 will already require HKDF support to be present.)
We use the key exchange algorithm name (e.g. "x25519") as additional
information to ensure separation between keys used for different
purposes. Since the initial random seed is generated afresh for each
connection, and since there can meaningfully be only one ephemeral
private key per key exchange algorithm per connection, this is
sufficient to ensure separation.
Having instantiated this HKDF, we then also use it to generate the
client random bytes (with the label "client random"), to generate the
random portion of the pre-master secret for classic RSA key exchange
(with the label "classic pre-master"), and to generate the random
portion of record IVs (using the authentication header structure,
which is already guaranteed to be unique per record within a
connection). Doing this allows us to eliminate all other calls to the
RNG, and removes some potential failure paths.
We reset the HKDF on a connection restart and on connection close, to
preserve the property of forward secrecy.
Michael Brown [Sat, 20 Jun 2026 09:00:44 +0000 (10:00 +0100)]
[crypto] Allow for input keying material to overlap output
Calling hkdf_extract() with no salt and with the input keying material
provided in the same buffer that will hold the output pseudorandom key
is a valid potential use case. This will currently fail silently
since the input keying material would be overwritten by the
constructed all-zero salt before being consumed.
Fix by using a local buffer for the all-zero salt, rather than
constructing the salt in the output buffer.
Document the permitted behaviour in terms of overlapping input and
output buffers for both hkdf_extract() and hkdf_expand(), and extend
the test cases to verify this behaviour.
Michael Brown [Fri, 19 Jun 2026 13:53:03 +0000 (14:53 +0100)]
[crypto] Use private data field for public-key algorithms
Following the example of commit 25072c1 ("[crypto] Use private data
field for key exchange algorithms"), extend the definition of a
public-key algorithm to include an opaque private data field, and use
this to eliminate the wrapper functions for PKCS#1 and RSA-PSS.
Michael Brown [Fri, 19 Jun 2026 13:11:46 +0000 (14:11 +0100)]
[crypto] Allow cipher_setiv() to return an error
GCM ciphers can accept initialisation vectors of any length. Move the
responsibility for checking the initialisation vector length from the
caller into the implementation of cipher_setiv().
Michael Brown [Fri, 19 Jun 2026 12:26:00 +0000 (13:26 +0100)]
[crypto] Use private data field for cipher algorithms
Following the example of commit 25072c1 ("[crypto] Use private data
field for key exchange algorithms"), extend the definition of a cipher
algorithm to include an opaque private data field, and use this to
eliminate the wrapper functions generated for the various block cipher
modes of operation by ECB_CIPHER(), CBC_CIPHER(), and GCM_CIPHER().
Michael Brown [Thu, 18 Jun 2026 14:54:19 +0000 (15:54 +0100)]
[crypto] Use private data field for digest algorithms
Following the example of commit 25072c1 ("[crypto] Use private data
field for key exchange algorithms"), extend the definition of a digest
algorithm to include an opaque private data field.
Michael Brown [Thu, 18 Jun 2026 13:21:08 +0000 (14:21 +0100)]
[crypto] Generalise notion of uncompressed elliptic curve points
With algorithm private data pointers now available, the general
mechanism for key exchange using uncompressed elliptic curve points
can be separated from the Weierstrass curve implementation.
Generalise the mechanism for performing elliptic curve key exchange
using uncompressed affine co-ordinates.
Michael Brown [Thu, 18 Jun 2026 12:18:18 +0000 (13:18 +0100)]
[crypto] Use private data field for elliptic curve algorithms
Following the example of commit 25072c1 ("[crypto] Use private data
field for key exchange algorithms"), extend the definition of an
elliptic curve to include an opaque private data field, and use this
to eliminate the wrapper functions generated by WEIERSTRASS_CURVE().
Michael Brown [Wed, 17 Jun 2026 14:13:34 +0000 (15:13 +0100)]
[tls] Accept only explicitly supported FFDHE groups
We do not currently perform any validation on the DHE field prime or
generator. RFC 7919 defines a family of known-safe finite fields, and
TLS version 1.3 completely removes the ability to provide an explicit
field prime and generator.
Verify that the field prime and generator correspond to one of the
explicitly configured groups.
This may break connections to the (now very rare) TLS servers that use
custom FFDHE groups and that choose to use DHE rather than ECDHE (or
that do not support ECDHE). We already advertise ECDHE cipher suites
as preferred over DHE cipher suites, and advertise all ECDHE groups as
preferred over all FFDHE groups. It is therefore very unlikely that
this change will cause any issues in practice.
Michael Brown [Wed, 17 Jun 2026 14:38:01 +0000 (15:38 +0100)]
[tls] Prefer X25519 as a key exchange mechanism
In TLS version 1.3, the expected flow is that the client offers at
least one key share in the initial ClientHello, so that key exchange
can take place as soon as the ServerHello is received (without
requiring a HelloRetryRequest and a second round trip).
We cannot viably offer key shares for all supported groups, since the
FFDHE groups have large public key values. The most likely approach
will be that we offer a single key share for our most preferred group.
Experiments suggest that X25519 is currently the most widely supported
key exchange group. Make this the most preferred group to maximise
the chance that a (future) TLS version 1.3 handshake will avoid the
extra round trip for a HelloRetryRequest.
Michael Brown [Wed, 17 Jun 2026 11:30:52 +0000 (12:30 +0100)]
[crypto] Provide a mechanism to check FFDHE group parameters
Provide is_ffdhe() and ffdhe_has_params() as a way to check if a key
exchange algorithm happens to match against an explicit pair of prime
modulus and generator values.
Michael Brown [Wed, 17 Jun 2026 09:48:18 +0000 (10:48 +0100)]
[crypto] Use private data field for key exchange algorithms
For historical reasons, TLS versions 1.2 and earlier identify FFDHE
groups by specifying the raw group prime and generator (the "dh_p" and
"dh_g" fields in ServerDHParams), rather than using a numeric code to
identify a named group.
This adds complexity to the process of identifying the internal key
exchange algorithm. One option would be to extend the definition of
struct tls_key_exchange_algorithm to include the identifying values
for the field prime and generator, but this is undesirable since the
field prime values may be large, and these values are already
available (indirectly) in ffdhe.c.
Extend our definition of a key exchange algorithm to include an opaque
private data field. This allows us to remove the wrapper functions
currently created by FFDHE_GROUP() and WEIERSTRASS_CURVE(), and opens
up the option of accessing the existing FFDHE field prime and
generator values from within the TLS layer.
The family of finite fields defined in RFC 7919 is almost identical to
that defined in RFC 3526, with the difference being that the older
standard uses the constant "pi" rather than "e".
Extend the definition of an FFDHE group to include a pointer to the
group constant, add the value of "pi", and define the modp2048,
modp3072, and modp4096 FFDHE groups.
Michael Brown [Tue, 16 Jun 2026 15:07:09 +0000 (16:07 +0100)]
[crypto] Use inline assembly for bigint_grow() and bigint_shrink()
The bigint_grow() and bigint_shrink() functions are used on the fast
path for big integer calculations (e.g. within the X25519 Montgomery
ladder step). Use inline assembly implementations of these functions
on all architectures.
Michael Brown [Tue, 16 Jun 2026 13:40:36 +0000 (14:40 +0100)]
[s390x] Use XOR-in-place to zero small fixed-length blocks
The XOR instruction has a storage-and-storage format "xc" that can be
used to zero small blocks of memory without needing to set up the four
registers required for "mvcle".
Michael Brown [Tue, 16 Jun 2026 13:20:41 +0000 (14:20 +0100)]
[tls] Rename "named curve" to "named group"
RFC 7919 renames the NamedCurve enumeration to NamedGroup, reflecting
its extended usage to handle key exchange groups that are not
constructed using elliptic curves.
Michael Brown [Tue, 16 Jun 2026 12:04:01 +0000 (13:04 +0100)]
[virtio] Ignore capabilities that describe inaccessible PCI BARs
In some configurations, newer versions of QEMU will end up placing the
modern interface's BAR4 above 4GB, rendering it inaccessible in a
32-bit build of iPXE. We will currently detect the existence of the
modern interface and attempt to use it, but fail at the point of
attempting to map the PCI BARs.
Fix by ignoring any virtio capabilities that describe an inaccessible
PCI BAR, and thereby allowing iPXE to fall back to using the legacy
interface if the modern interface's BAR cannot be used.
Reported-by: Jan ONDREJ (SAL) <ondrejj@salstar.sk> Signed-off-by: Michael Brown <mcb30@ipxe.org>
Michael Brown [Mon, 15 Jun 2026 15:11:12 +0000 (16:11 +0100)]
[settings] Allow system time to be modified via builtin/unixtime
Allow the system time offset to be modified by writing a new time
value to builtin/unixtime, e.g.:
set builtin/unixtime 0x10d1a884
As with the NTP client, this does not attempt to write to the
underlying clock source (e.g. the RTC clock). Only the internal
system time offset is updated.
Any system time offset may be reset by clearing the setting:
clear builtin/unixtime
This will reset the system time offset to zero and so can be used to
undo the effect of a previous "set builtin/unixtime" or "ntp" command.
Requested-by: Christian I. Nilsson <ChristianN@2PintSoftware.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
Michael Brown [Sun, 14 Jun 2026 16:15:55 +0000 (17:15 +0100)]
[s390x] Add optimised TCP/IP checksumming
Add an S/390 assembly language implementation of TCP/IP checksumming,
using the hardware "cksm" instruction to first calculate the 32-bit
one's complement checksum and then folding down to 16 bits.
Use an inline function since the whole checksum calculation (including
folding) requires only six instructions.
Michael Brown [Sat, 13 Jun 2026 15:15:57 +0000 (16:15 +0100)]
[test] Fix RFC 1071 checksum calculation for big-endian targets
Calculation of the TCP/IP checksum is fundamentally endian-agnostic:
the checksum is designed to be symmetric so that both big-endian and
little-endian systems can use native addition in any word size without
any byte swapping. The result is then stored into the checksum field
in the packet header as a native-endian value.
The reference algorithm presented in RFC 1071 (and used in our test
suite) is implicitly little-endian: the trailing byte is on a 16-bit
word boundary and is added to the least significant byte of the 16-bit
checksum value.
Fix by shifting the trailing byte by 8 bits on big-endian targets.
Michael Brown [Sat, 13 Jun 2026 15:07:41 +0000 (16:07 +0100)]
[efi] Fix parsing of EFI signature lists on big-endian targets
Though UEFI is fundamentally little-endian, the EFI signature list
image format is available even on non-EFI platforms (and is covered by
the unit test suite).
Add le32_to_cpu() macros as needed to allow EFI signature lists to be
parsed correctly on big-endian targets.
Michael Brown [Sat, 13 Jun 2026 15:03:33 +0000 (16:03 +0100)]
[peerdist] Fix segment identifier constant on big-endian targets
The "MS_P2P_CACHING" constant (used as part of the HMAC digest
calculation for the segment identifier) is a UTF-16LE string. On a
big-endian target, a wide-character string literal will have the wrong
endianness.
Fix by using a byte array rather than a wide-character string.
Michael Brown [Sat, 13 Jun 2026 15:01:35 +0000 (16:01 +0100)]
[build] Fix building for big-endian targets
Fix build errors that arise when building for a big-endian target such
as s390x. (Runtime endianness errors may remain: this fixes only
those errors that are detected at build time.)
Michael Brown [Sat, 13 Jun 2026 14:28:52 +0000 (15:28 +0100)]
[crypto] Use generic implementations of slow-path big integer functions
In the original big integer implementation, big integers were entirely
opaque to the caller and only the architecture-dependent code knew any
details of the internal structure.
This has long since ceased to be the case: for the sake of arithmetic
efficiency, many portions of the codebase now presume that big
integers are represented as an array of elements, with each element
being a native-endian unsigned value (with the precise type being
chosen by the architecture-specific header file) and with the least
significant element being first in the array.
The functions bigint_init(), bigint_done(), bigint_is_zero(),
bigint_is_geq(), and bigint_max_bit_set() are never used on fast code
paths, and most architectures use a generic C implementation of these
functions.
Provide generic implementations of these slow-path functions to be
used on all architectures.
We currently support fully parameterized finite field Diffie-Hellman
key exchange, where the peer provides not only its public key but also
the (fully arbitrary) selection of the field prime and generator.
RFC 7919 defines a family of finite fields all constructed from the
natural logarithm constant "e", intended to be used as well-known
fields where the peer simply names the field (e.g. "ffdhe2048") rather
than providing the raw prime and generator values.
Add support for this family of finite fields as key exchange
algorithms, to allow for protocols such as TLS version 1.3 where
parameterized fields are not permitted.
We choose to support only up to ffdhe4096, since this is sufficient to
exceed the security strength of our RNG (128 bits).
Support for ffdhe6144 and ffdhe8192 could trivially be added by simply
extending the "euler" constant and adding the relevant FFDHE_GROUP()
declarations. Doing so would approximately double the space
requirements for both read-only data (from 0.5kB to 1kB) and for
uninitialised data (from 3.5kB to 7kB).
Michael Brown [Sat, 6 Jun 2026 15:51:20 +0000 (16:51 +0100)]
[crypto] Remove redundant ECDHE algorithm
Remove the now-unused implementation of ECDHE that requires an
underlying elliptic curve abstraction, since we now use a standalone
key exchange algorithm abstraction instead.
Michael Brown [Sat, 6 Jun 2026 15:43:09 +0000 (16:43 +0100)]
[crypto] Remove elliptic curve abstraction for X25519
X25519 is defined as a key exchange algorithm, not as a generic
elliptic curve. We have never supported arbitrary point addition on
the underlying curve, and we have never supported pure multiplication
(without the clamping defined in RFC7748, which modifies the scalar
multiple).
Now that we have an abstraction for key exchange that exists
independently of the elliptic curve abstraction, there are no further
consumers of the elliptic curve abstraction for X25519. Remove this
redundant abstraction to simplify the codebase.
Michael Brown [Fri, 5 Jun 2026 15:56:41 +0000 (16:56 +0100)]
[crypto] Provide Weierstrass curves as generic key exchange algorithms
Provide the Weierstrass curves P-256 and P-384 as generic key exchange
algorithms (independent of the elliptic curve abstraction). Only the
"uncompressed" point format is supported, and the knowledge of the
format byte is internalised within the key exchange algorithm so that
the caller can just treat all values as opaque byte strings.
Add a random selection of the NIST "ECC CDH Primitive (SP800-56A
Section 5.7.1.2)" key exchange test vectors.
Michael Brown [Fri, 5 Jun 2026 14:07:33 +0000 (15:07 +0100)]
[crypto] Provide X25519 as a generic key exchange algorithm
Provide X25519 as a generic key exchange algorithm (independent of the
elliptic curve abstraction).
The existing RFC7748 test vectors are not structured in a way amenable
to treatment as a generic key exchange algorithm. Retain these test
vectors unaltered for completeness, add the single "Alice/Bob" key
exchange example presented in RFC7748, and add a selection of test
vectors from Project Wycheproof (including some known edge cases).
Michael Brown [Fri, 5 Jun 2026 13:59:29 +0000 (14:59 +0100)]
[crypto] Add a generic concept of a key exchange algorithm
TLS version 1.3 does not use static RSA or parameterized DHE for key
exchange: all key exchange algorithms are identified via a "named
group" enumeration and have predefined group parameters with fixed
input and output sizes.
Add an abstraction of a key exchange algorithm matching this usage
pattern, along with corresponding test support code.
projects / thirdparty / ipxe.git / log
