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.
Michael Brown [Tue, 11 Nov 2025 14:45:01 +0000 (14:45 +0000)]
[efi] Switch back to VA_START() etc macros for EFIAPI functions
Commit 670810b ("[efi] Use standard va_args macros instead of
VA_START() etc") fixed a 32-bit RISC-V build error, but broke the
functionality of the InstallMultipleProtocolInterfaces() and
UninstallMultipleProtocolInterfaces() wrapper functions. GCC does not
automatically check the ABI of the current function when using the
__builtin_va_start() and related macros, and it is therefore necessary
for code to use __builtin_ms_va_start() etc from within functions
marked as EFIAPI.
Since commit 9016f2e ("[efi] Skip including the EDK2 ProcessorBind.h
header for 32-bit RISC-V") has now fixed the original 32-bit RISC-V
build error, we can switch back to using the EDK2 VA_START() etc
macros to obtain the correct behaviour.
Michael Brown [Tue, 11 Nov 2025 14:38:59 +0000 (14:38 +0000)]
[efi] Skip including the EDK2 ProcessorBind.h header for 32-bit RISC-V
We currently include the EDK2 RiscV64/ProcessorBind.h header when
building for 32-bit RISC-V, as a placeholder since there is no support
for 32-bit RISC-V in upstream EDK2.
This causes errors when attempting to use the EDK2 VA_START() et al
macros, since RiscV64/ProcessorBind.h ends up defining UINTN with a
size different from the size of a pointer.
Fix by falling back to the generic definitions for UINTN etc (as used
for EFI_HOSTONLY) whenever we don't have an architecture-specific
ProcessorBind.h header available.
Michael Brown [Wed, 5 Nov 2025 20:06:53 +0000 (20:06 +0000)]
[spcr] Accept alternative type value for a 16550-compatible UART
Some systems (observed on an AWS EC2 m7i.metal-24xl instance in
eu-south-2) use the newer "16550-compatible with parameters defined in
Generic Address Structure" type value. (There does not appear to be
any particular reason why the newer value needs to be used: the UART
is still a standard 16550 with single-byte registers.)
Accept this additional type value for a 16550-compatible UART.
Michael Brown [Wed, 5 Nov 2025 17:39:43 +0000 (17:39 +0000)]
[acpi] Allow acpi_ioremap() to map a port I/O address
Assume that on any platforms where port I/O is used (i.e. x86), a port
I/O address may be used directly for the combined MMIO and port I/O
accessors without requiring an explicit mapping operation.
Michael Brown [Wed, 5 Nov 2025 17:29:39 +0000 (17:29 +0000)]
[ioapi] Allow iounmap() to be called for port I/O addresses
Allow code using the combined MMIO and port I/O accessors to safely
call iounmap() to unmap the MMIO or port I/O region.
In the virtual offset I/O mapping API as used for UEFI, 32-bit BIOS,
and 32-bit RISC-V SBI, iounmap() is a no-op anyway. In 64-bit RISC-V
SBI, we have no concept of port I/O and so the issue is moot.
This leaves only 64-bit BIOS, where it suffices to simply do nothing
for any pages outside of the chosen MMIO virtual address range.
For symmetry, we implement the equivalent change in the very closely
related RISC-V page management code.
Michael Brown [Wed, 5 Nov 2025 14:19:56 +0000 (14:19 +0000)]
[spcr] Use the serial port defined by the ACPI SPCR by default
On platforms where we expect ACPI tables to exist, use the serial port
defined by the ACPI Serial Port Console Redirection (SPCR) table by
default, falling back to the fixed serial port defined at build time.
Michael Brown [Wed, 5 Nov 2025 14:12:57 +0000 (14:12 +0000)]
[spcr] Add support for the ACPI Serial Port Console Redirection table
The BIOS may provide an ACPI Serial Port Console Redirection (SPCR)
table to describe the serial port to be used for early boot messages.
Add support for parsing the SPCR and instantiating a 16550-based UART.
We do not currently attempt to support other types of UART, since iPXE
does not yet have drivers for other types.
Michael Brown [Wed, 5 Nov 2025 14:07:27 +0000 (14:07 +0000)]
[acpi] Add acpi_ioremap() to map an ACPI-described address
An ACPI Generic Address Structure (GAS) may be used to describe the
location of a peripheral such as an early boot console. Add the
relevant definitions and provide acpi_ioremap() as a helper function
to map a region described using this structure.
Michael Brown [Wed, 5 Nov 2025 12:16:22 +0000 (12:16 +0000)]
[uart] Make baud rate a property of the UART
Make the current baud rate (if specified) a property of the UART, to
allow the default_serial_console() function to specify the default
baud rate as well as the default UART device.
Michael Brown [Tue, 4 Nov 2025 16:43:44 +0000 (16:43 +0000)]
[uart] Support 16550 UARTs accessed via either MMIO or port I/O
Use the combined accessors ioread8() and iowrite8() to read and write
16550 UART registers, to allow the decision between using MMIO and
port I/O to be made at runtime.
Minimise the increase in code size for x86 by ignoring the register
shift, since this is essentially used only for non-x86 SoCs.
Michael Brown [Tue, 4 Nov 2025 16:19:03 +0000 (16:19 +0000)]
[ioapi] Provide combined MMIO and port I/O accessors
Some devices (such as a 16550 UART) may be accessed via either MMIO or
port I/O. This is currently forced to be a compile-time decision.
For example: we currently access a 16550 UART via port I/O on x86 and
via MMIO on any other platform.
PCI UARTs with MMIO BARs do exist but are not currently supported in
an x86 build of iPXE. Some AWS EC2 systems (observed on a c6i.metal
instance in eu-west-2) provide only a PCI MMIO UART, and it is
therefore currently impossible to get serial output from iPXE on these
instance types.
Add ioread8(), ioread16(), etc accessors that will select between MMIO
and port I/O at the point of use. For non-x86 platforms where we
currently have no port I/O support, these simply become wrappers
around the corresponding readb(), readw(), etc MMIO accessors. On
x86, we use the fairly well-known trick of treating any 16-bit address
(below 64kB) as a port I/O address.
This trick works even in the i386 BIOS build of iPXE (where virtual
addresses are offset from physical addresses by a runtime constant),
since the first 64kB of the virtual address space will correspond to
the iPXE binary itself (along with its uninitialised-data space), and
so must be RAM rather than a valid MMIO address range.
Michael Brown [Wed, 29 Oct 2025 23:07:32 +0000 (23:07 +0000)]
[pci] Disable decoding while setting a BAR value
Setting the base address for a 64-bit BAR requires two separate 32-bit
writes to configuration space, and so will necessarily result in the
BAR temporarily holding an invalid partially written address.
Some hypervisors (observed on an AWS EC2 c7a.medium instance in
eu-west-2) will assume that guests will write BAR values only while
decoding is disabled, and may not rebuild MMIO mappings for the guest
if the BAR registers are written while decoding is enabled. The
effect of this is that MMIO accesses are not routed through to the
device even though inspection from within the guest shows that every
single PCI configuration register has the correct value. Writes to
the device will be ignored, and reads will return the all-ones pattern
that typically indicates a nonexistent device.
With the ENA network driver now using low latency transmit queues,
this results in the transmit descriptors being lost (since the MMIO
writes to BAR2 never reach the device), which in turn causes the
device to lock up as soon as the transmit doorbell is rung for the
first time.
Fix by disabling decoding of memory and I/O cycles while setting a BAR
address (as we already do while sizing a BAR), so that the invalid
partial address can never be decoded and so that hypervisors will
rebuild MMIO mappings as expected.
Michael Brown [Wed, 29 Oct 2025 13:18:28 +0000 (13:18 +0000)]
[cloud] Display instance type in AWS EC2
Experiments suggest that the instance type is exposed via the SMBIOS
product name. Include this information within the default output,
since it is often helpful in debugging.
Michael Brown [Mon, 27 Oct 2025 12:41:36 +0000 (12:41 +0000)]
[ena] Leave queue base address empty when creating a low latency queue
The queue base address is meaningless for a low latency queue, since
the queue entries are written directly to the on-device memory. Any
non-zero queue base address will be safely ignored by the hardware,
but leaves open the possibility that future revisions could treat it
as an error.
Leave this field as zero, to match the behaviour of the Linux driver.
Michael Brown [Mon, 20 Oct 2025 11:35:36 +0000 (12:35 +0100)]
[cloud] Display build architecture in AWS EC2
On some newer (7th and 8th generation) instance types, the 32-bit
build of iPXE cannot access PCI configuration space since the ECAM is
placed outside of the 32-bit address space. The visible symptom is
that iPXE fails to detect any network devices.
The public AMIs are all now built as 64-bit binaries, but there is
nothing that prevents the building and importing of a 32-bit AMI.
There are still potentially valid use cases for 32-bit AMIs (e.g. if
planning to use the AMI only for older instance types), and so we
cannot sensibly prevent this error at build time.
Display the build architecture as part of the AWS EC2 embedded script,
to at least allow for easy identification of this particular failure
mode at run time.
Michael Brown [Fri, 17 Oct 2025 11:35:11 +0000 (12:35 +0100)]
[ena] Limit receive queue size to work around hardware bugs
Commit a801244 ("[ena] Increase receive ring size to 128 entries")
increased the receive ring size to 128 entries (while leaving the fill
level at 16), since using a smaller receive ring caused unexplained
failures on some instance types.
The original hardware bug that resulted in that commit seems to have
been fixed: experiments suggest that the original failure (observed on
a c6i.large instance in eu-west-2) will no longer reproduce when using
a receive ring containing only 16 entries (as was the case prior to
that commit).
Newer generations of the ENA hardware (observed on an m8i.large
instance in eu-south-2) seem to have a new and exciting hardware bug:
these instance types appear to use a hash of the received packet
header to determine which portion of the (out-of-order) receive ring
to use. If that portion of the ring happens to be empty (e.g. because
only 32 entries of the 128-entry ring are filled at any one time),
then the packet will be silently dropped.
Work around this new hardware bug by reducing the receive ring size
down to the current fill level of 32 entries. This appears to work on
all current instance types (but has not been exhaustively tested).
Michael Brown [Thu, 16 Oct 2025 15:33:38 +0000 (16:33 +0100)]
[ena] Increase receive fill level
Experiments suggest that at least some instance types (observed with
c6i.large in eu-west-2) experience high packet drop rates with only 16
receive buffers allocated. Increase the fill level to 32 buffers.
Michael Brown [Thu, 16 Oct 2025 14:58:23 +0000 (15:58 +0100)]
[ena] Add support for low latency transmit queues
Newer generations of the ENA hardware require the use of low latency
transmit queues, where the submission queues and the initial portion
of the transmitted packet are written to on-device memory via BAR2
instead of being read from host memory.
Detect support for low latency queues and set the placement policy
appropriately. We attempt the use of low latency queues only if the
device reports that it supports inline headers, 128-byte entries, and
two descriptors prior to the inlined header, on the basis that we
don't care about using low latency queues on older versions of the
hardware since those versions will support normal host memory
submission queues anyway.
We reuse the redundant memory allocated for the submission queue as
the bounce buffer for constructing the descriptors and inlined packet
data, since this avoids needing a separate allocation just for the
bounce buffer.
We construct a metadata submission queue entry prior to the actual
submission queue entry, since experimentation suggests that newer
generations of the hardware require this to be present even though it
conveys no information beyond its own existence.
Michael Brown [Wed, 15 Oct 2025 14:27:03 +0000 (15:27 +0100)]
[ena] Map the on-device memory, if present
Newer generations of the ENA hardware require the use of low latency
transmit queues, where the submission queues and the initial portion
of the transmitted packet are written to on-device memory via BAR2
instead of being read from host memory.
Prepare for this by mapping the on-device memory BAR. As with the
register BAR, we may need to steal a base address from the upstream
PCI bridge since the BIOS on some instance types (observed with an
m8i.metal-48xl instance in eu-south-2) will fail to assign an address
to the device.
Michael Brown [Tue, 14 Oct 2025 13:44:56 +0000 (14:44 +0100)]
[ena] Use pci_bar_set() to place device within bridge memory window
Use pci_bar_set() when we need to set a device base address (on
instance types such as c6i.metal where the BIOS fails to do so), so
that 64-bit BARs will be handled automatically.
This particular issue has so far been observed only on 6th generation
instances. These use 32-bit BARs, and so the lack of support for
handling 64-bit BARs has not caused any observable issue.
Michael Brown [Tue, 14 Oct 2025 12:46:54 +0000 (13:46 +0100)]
[pci] Handle sizing of 64-bit BARs
Provide pci_bar_set() to handle setting the base address for a
potentially 64-bit BAR, and rewrite pci_bar_size() to correctly handle
sizing of 64-bit BARs.
Michael Brown [Sun, 12 Oct 2025 21:37:49 +0000 (22:37 +0100)]
[tls] Disable renegotiation unless extended master secret is used
RFC 7627 states that renegotiation becomes no longer secure under
various circumstances when the non-extended master secret is used.
The description of the precise set of circumstances is spread across
various points within the document and is not entirely clear.
Avoid a superset of the circumstances in which renegotiation
apparently becomes insecure by refusing renegotiation completely
unless the extended master secret is used.
Michael Brown [Sun, 12 Oct 2025 21:29:33 +0000 (22:29 +0100)]
[tls] Refuse to resume sessions with mismatched master secret methods
RFC 7627 section 5.3 states that the client must abort the handshake
if the server attempts to resume a session where the master secret
calculation method stored in the session does not match the method
used for the connection being resumed.
Michael Brown [Sun, 12 Oct 2025 21:26:49 +0000 (22:26 +0100)]
[tls] Add support for the Extended Master Secret
RFC 7627 defines the Extended Master Secret (EMS) as an alternative
calculation that uses the digest of all handshake messages rather than
just the client and server random bytes.
Add support for negotiating the Extended Master Secret extension and
performing the relevant calculation of the master secret.
projects / thirdparty / ipxe.git / log
