summaryrefslogtreecommitdiffstats
path: root/src
Commit message (Collapse)AuthorAgeFilesLines
* Merge branch 'master' into openslxopenslxSimon Rettberg2026-01-281515-13829/+49280
|\
| * [prefix] Make unlzma.S compatible with 386 class CPUsJaromir Capik2026-01-251-2/+4
| | | | | | | | | | | | | | | | | | Replace the bswap instruction with xchgb and roll and change the module architecture from i486 to i386 to be consistent with the rest of the project. Modified-by: Michael Brown <mcb30@ipxe.org> Signed-off-by: Michael Brown <mcb30@ipxe.org>
| * [build] Allow GITVERSION to be specified as an environment variableMichael Brown2026-01-251-10/+7Star
| | | | | | | | | | | | | | | | | | | | | | 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. Signed-off-by: Michael Brown <mcb30@ipxe.org>
| * [build] Do not use "git log" to construct build timestampMichael Brown2026-01-221-2/+0Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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. Signed-off-by: Michael Brown <mcb30@ipxe.org>
| * [build] Do not use "git describe" to construct version numberMichael Brown2026-01-211-15/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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. Signed-off-by: Michael Brown <mcb30@ipxe.org>
| * [build] Allow for per-architecture sysrootsMichael Brown2026-01-211-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 export SYSROOT_riscv32=/usr/riscv32-linux-gnu/sys-root 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. Signed-off-by: Michael Brown <mcb30@ipxe.org>
| * [build] Extend default configuration for non-BIOS buildsMichael Brown2026-01-163-17/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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. Signed-off-by: Michael Brown <mcb30@ipxe.org>
| * [usb] Drag in USB commands only when USB support is presentMichael Brown2026-01-162-3/+8
| | | | | | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
| * [pci] Drag in PCI commands only when PCI support is presentMichael Brown2026-01-162-3/+4
| | | | | | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
| * [build] Canonicalise console type configurationMichael Brown2026-01-165-39/+58
| | | | | | | | | | | | | | | | | | 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. Signed-off-by: Michael Brown <mcb30@ipxe.org>
| * [build] Canonicalise USB configurationMichael Brown2026-01-163-33/+15Star
| | | | | | | | | | | | | | | | 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. Signed-off-by: Michael Brown <mcb30@ipxe.org>
| * [build] Canonicalise settings sources configurationMichael Brown2026-01-162-9/+21
| | | | | | | | | | | | | | | | 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. Signed-off-by: Michael Brown <mcb30@ipxe.org>
| * [build] Sort general configuration in order of approachabilityMichael Brown2026-01-161-121/+113Star
| | | | | | | | | | | | | | | | | | 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. Signed-off-by: Michael Brown <mcb30@ipxe.org>
| * [build] Canonicalise remaining portions of general configurationMichael Brown2026-01-163-41/+46
| | | | | | | | | | | | | | | | 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. Signed-off-by: Michael Brown <mcb30@ipxe.org>
| * [build] Canonicalise SAN boot protocol configurationMichael Brown2026-01-164-24/+10Star
| | | | | | | | | | | | | | | | 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. Signed-off-by: Michael Brown <mcb30@ipxe.org>
| * [build] Canonicalise download protocol configurationMichael Brown2026-01-162-10/+14
| | | | | | | | | | | | | | | | 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. Signed-off-by: Michael Brown <mcb30@ipxe.org>
| * [build] Canonicalise network protocol configurationMichael Brown2026-01-162-11/+16
| | | | | | | | | | | | | | | | 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. Signed-off-by: Michael Brown <mcb30@ipxe.org>
| * [build] Canonicalise command list configurationMichael Brown2026-01-165-50/+56
| | | | | | | | | | | | | | | | 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. Signed-off-by: Michael Brown <mcb30@ipxe.org>
| * [build] Canonicalise image type configurationMichael Brown2026-01-155-39/+50
| | | | | | | | | | | | | | | | 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. Signed-off-by: Michael Brown <mcb30@ipxe.org>
| * [build] Mark more reviewed files as permitted for UEFI Secure BootMichael Brown2026-01-144-0/+4
| | | | | | | | | | | | | | | | | | 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 <mcb30@ipxe.org>
| * [build] Fail Secure Boot builds unless all files are permittedMichael Brown2026-01-142-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add the Secure Boot permissibility check as a dependency for targets built with the Secure Boot flag enabled. Attempting to build e.g. make bin-x86_64-efi-sb/snponly.efi will now fail unless all files used in the final binary are marked as being permitted for Secure Boot. This does not affect the standard build targets (without the "-sb" suffix on the build directory). Signed-off-by: Michael Brown <mcb30@ipxe.org>
| * [build] Mark MD4 and MD5 as forbidden for UEFI Secure BootMichael Brown2026-01-144-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.) Signed-off-by: Michael Brown <mcb30@ipxe.org>
| * [build] Mark known reviewed files as permitted for UEFI Secure BootMichael Brown2026-01-14304-0/+306
| | | | | | | | | | | | | | | | | | 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 <mcb30@ipxe.org>
| * [build] Mark core files as permitted for UEFI Secure BootMichael Brown2026-01-14497-0/+498
| | | | | | | | | | | | | | | | | | | | | | | | 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 <mcb30@ipxe.org>
| * [build] Check for standalone FILE_LICENCE() and FILE_SECBOOT() declarationsMichael Brown2026-01-141-3/+12
| | | | | | | | | | | | | | | | | | 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. Signed-off-by: Michael Brown <mcb30@ipxe.org>
| * [console] Mark generated keymaps as permitted for Secure BootMichael Brown2026-01-1331-0/+31
| | | | | | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
| * [build] Mark existing files as explicitly forbidden for Secure BootMichael Brown2026-01-1395-15/+141
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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. Signed-off-by: Michael Brown <mcb30@ipxe.org>
| * [efi] Mark imported EDK2 headers as permitted for Secure BootMichael Brown2026-01-13126-2/+129
| | | | | | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
| * [efi] Update to current EDK2 headersMichael Brown2026-01-131-22/+22
| | | | | | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
| * [build] Define a mechanism for marking Secure Boot permissibilityMichael Brown2026-01-132-8/+63
| | | | | | | | | | | | | | | | | | | | | | | | 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. Signed-off-by: Michael Brown <mcb30@ipxe.org>
| * [neighbour] Treat delayed transmissions as pending operationsMichael Brown2026-01-101-0/+12
| | | | | | | | | | | | | | | | 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. Signed-off-by: Michael Brown <mcb30@ipxe.org>
| * [tcp] Report TCP statistics via the "ipstat" commandMichael Brown2026-01-093-2/+49
| | | | | | | | | | | | | | | | | | | | | | 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. Signed-off-by: Michael Brown <mcb30@ipxe.org>
| * [malloc] Increase heap size to 4MBMichael Brown2026-01-091-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <mcb30@ipxe.org>
| * [tcp] Discard packets that lie immediately before the receive windowMichael Brown2026-01-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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. Signed-off-by: Michael Brown <mcb30@ipxe.org>
| * [neighbour] Add the ability to artificially delay outbound packetsMichael Brown2026-01-063-3/+80
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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. Signed-off-by: Michael Brown <mcb30@ipxe.org>
| * [neighbour] Split out deferred transmission from discovery completionMichael Brown2026-01-061-14/+28
| | | | | | | | | | | | | | | | 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. Signed-off-by: Michael Brown <mcb30@ipxe.org>
| * [neighbour] Use discovery protocol field to identify incomplete neighboursMichael Brown2026-01-063-22/+19Star
| | | | | | | | | | | | | | | | | | 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. Signed-off-by: Michael Brown <mcb30@ipxe.org>
| * [neighbour] Always use network device's own link-layer addressMichael Brown2026-01-056-15/+10Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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. Signed-off-by: Michael Brown <mcb30@ipxe.org>
| * [crypto] Allow for zero-length big integer literalsMichael Brown2025-12-293-4/+15
| | | | | | | | | | | | | | | | | | | | 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(). Signed-off-by: Michael Brown <mcb30@ipxe.org>
| * [test] Update big integer tests to use okx()Michael Brown2025-12-291-292/+428
| | | | | | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
| * [crypto] Fix identification of non-wrapped elliptic curve identifiersMichael Brown2025-12-221-2/+2
| | | | | | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
| * [crypto] Add ECDSA-based TLS cipher suitesMichael Brown2025-12-197-0/+277
| | | | | | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
| * [test] Add test cases for X.509 certificates with ECDSA signaturesMichael Brown2025-12-191-0/+271
| | | | | | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
| * [crypto] Add OID-identified algorithms for ECDSA with SHA2 hash familyMichael Brown2025-12-198-0/+252
| | | | | | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
| * [crypto] Allow ecPublicKey to be identified as a public-key algorithmMichael Brown2025-12-193-18/+23
| | | | | | | | | | | | | | | | 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. Signed-off-by: Michael Brown <mcb30@ipxe.org>
| * [test] Ensure OID-identified algorithms are present for X.509 testsMichael Brown2025-12-191-3/+2Star
| | | | | | | | | | | | | | | | | | 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. Signed-off-by: Michael Brown <mcb30@ipxe.org>
| * [x509] Correct debug messageMichael Brown2025-12-191-1/+1
| | | | | | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
| * [crypto] Add support for ECDSA signaturesMichael Brown2025-12-195-0/+1223
| | | | | | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
| * [test] Test verification of constructed signatureMichael Brown2025-12-191-0/+4
| | | | | | | | | | | | | | | | | | | | | | 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. Signed-off-by: Michael Brown <mcb30@ipxe.org>
| * [crypto] Allow for an explicit representation of point at infinityMichael Brown2025-12-1811-58/+225
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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). Signed-off-by: Michael Brown <mcb30@ipxe.org>
generated by cgit v1.2.3-55-g7522 (git 2.39.0) at 2026-03-04 09:51:11 +0100