openslx-ng/ipxe.git/src/core, branch openslx

Merge branch 'master' into openslx

2026-01-28T11:53:53+00:00

[build] Mark more reviewed files as permitted for UEFI Secure Boot

2026-01-14T22:51:04+00:00

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. Signed-off-by: Michael Brown

[build] Mark known reviewed files as permitted for UEFI Secure Boot

2026-01-14T16:10:29+00:00

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. Signed-off-by: Michael Brown

[build] Mark core files as permitted for UEFI Secure Boot

2026-01-14T13:25:34+00:00

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. Signed-off-by: Michael Brown

[malloc] Increase heap size to 4MB

2026-01-09T15:20:25+00:00

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: * 1460-byte MSS => 1436 packets => 2872kB of 2kB RX I/O buffers * 8960-byte MSS => 234 packets => 3744kB of 16kB RX I/O buffers 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. Signed-off-by: Michael Brown

[spcr] Accept alternative type value for a 16550-compatible UART

2025-11-05T20:06:53+00:00

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. Signed-off-by: Michael Brown

[acpi] Allow acpi_ioremap() to map a port I/O address

2025-11-05T19:33:53+00:00

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. Signed-off-by: Michael Brown

[spcr] Add support for the ACPI Serial Port Console Redirection table

2025-11-05T14:12:57+00:00

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. Signed-off-by: Michael Brown

[acpi] Add acpi_ioremap() to map an ACPI-described address

2025-11-05T14:10:14+00:00

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. Signed-off-by: Michael Brown

[uart] Make baud rate a property of the UART

2025-11-05T12:18:17+00:00

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. Signed-off-by: Michael Brown