aboutsummaryrefslogtreecommitdiffstats
path: root/src/include
Commit message (Collapse)AuthorAgeFilesLines
* [libc] Allow build_assert() failures to be ignored via NO_WERROR=1Michael Brown2024-02-101-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | We build with -Werror by default so that any warning is treated as an error and aborts the build. The build system allows NO_WERROR=1 to be used to override this behaviour, in order to allow builds to succeed when spurious warnings occur (e.g. when using a newer compiler that includes checks for which the codebase is not yet prepared). Some versions of gcc (observed with gcc 4.8.5 in CentOS 7) will report spurious build_assert() failures: the compilation will fail due to an allegedly unelided call to the build assertion's external function declared with __attribute__((error)) even though the compiler does manage to successfully elide the call (as verified by the fact that there are no unresolvable symbol references in the compiler output). Change build_assert() to declare __attribute__((warning)) instead of __attribute__((error)) on its extern function. This will still abort a normal build if the assertion fails, but may be overridden using NO_WERROR=1 if necessary to work around a spurious assertion failure. Note that if the build assertion has genuinely failed (i.e. if the compiler has genuinely not been able to elide the call) then the object will still contain an unresolvable symbol reference that will cause the link to fail (which matches the behaviour of the old linker_assert() mechanism). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Add implementation of the DES cipherMichael Brown2024-02-072-0/+92
| | | | | | | | | | | | | | The DES block cipher dates back to the 1970s. It is no longer relevant for use in TLS cipher suites, but it is still used by the MS-CHAPv2 authentication protocol which remains unfortunately common for 802.1x port authentication. Add an implementation of the DES block cipher, complete with the extremely comprehensive test vectors published by NBS (the precursor to NIST) in the form of an utterly adorable typewritten and hand-drawn paper document. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Fix stray references to AESMichael Brown2024-02-021-3/+3
| | | | | | | | | | The CBC_CIPHER() macro contains some accidentally hardcoded references to an underlying AES cipher, instead of using the cipher specified in the macro parameters. Fix by using the macro parameter as required. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [tls] Add ECDHE cipher suitesMichael Brown2024-01-311-0/+6
| | | | | | | Add ECDHE variants of the existing cipher suites, and lower the priority of the non-ECDHE variants. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Add X25519 OID-identified algorithm and TLS named curveMichael Brown2024-01-301-0/+7
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [tls] Add support for Ephemeral Elliptic Curve Diffie-Hellman key exchangeMichael Brown2024-01-301-0/+24
| | | | | | | Add support for the Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) key exchange algorithm. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Add an abstraction of an elliptic curveMichael Brown2024-01-302-0/+26
| | | | | | | Define an abstraction of an elliptic curve with a fixed generator and one supported operation (scalar multiplication of a curve point). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Check for all-zeros result from X25519 key exchangeMichael Brown2024-01-302-3/+4
| | | | | | | | | | | | | RFC7748 states that it is entirely optional for X25519 Diffie-Hellman implementations to check whether or not the result is the all-zero value (indicating that an attacker sent a malicious public key with a small order). RFC8422 states that implementations in TLS must abort the handshake if the all-zero value is obtained. Return an error if the all-zero value is obtained, so that the TLS code will not require knowledge specific to the X25519 curve. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Add X25519 key exchange algorithmMichael Brown2024-01-191-0/+91
| | | | | | | | | | | | | | | | | Add an implementation of the X25519 key exchange algorithm as defined in RFC7748. This implementation is inspired by and partially based upon the paper "Implementing Curve25519/X25519: A Tutorial on Elliptic Curve Cryptography" by Martin Kleppmann, available for download from https://www.cl.cam.ac.uk/teaching/2122/Crypto/curve25519.pdf The underlying modular addition, subtraction, and multiplication operations are completely redesigned for substantially improved efficiency compared to the TweetNaCl implementation studied in that paper (approximately 5x-10x faster and with 70% less memory usage). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Add bigint_swap() to conditionally swap big integersMichael Brown2024-01-191-0/+15
| | | | | | | Add a helper function bigint_swap() that can be used to conditionally swap a pair of big integers in constant time. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Add bigint_copy() as a convenient wrapper macroMichael Brown2024-01-191-0/+13
| | | | | | | | | | | Big integers may be efficiently copied using bigint_shrink() (which will always copy only the size of the destination integer), but this is potentially confusing to a reader of the code. Provide bigint_copy() as an alias for bigint_shrink() so that the intention of the calling code may be more obvious. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Allow multiplicand and multiplier to differ in sizeMichael Brown2024-01-161-5/+7
| | | | | | | | | | | Big integer multiplication is currently used only as part of modular exponentiation, where both multiplicand and multiplier will be the same size. Relax this requirement to allow for the use of big integer multiplication in other contexts. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [libc] Replace linker_assert() with build_assert()Michael Brown2024-01-164-45/+36
| | | | | | | | | | | | | | | | | | | | | | | We currently implement build-time assertions via a mechanism that generates a call to an undefined external function that will cause the link to fail unless the compiler can prove that the asserted condition is true (and thereby eliminate the undefined function call). This assertion mechanism can be used for conditions that are not amenable to the use of static_assert(), since static_assert() will not allow for proofs via dead code elimination. Add __attribute__((error(...))) to the undefined external function, so that the error is raised at compile time rather than at link time. This allows us to provide a more meaningful error message (which will include the file name and line number, as with any other compile-time error), and avoids the need for the caller to specify a unique symbol name for the external function. Change the name from linker_assert() to build_assert(), since the assertion now takes place at compile time rather than at link time. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [libc] Make static_assert() available via assert.hassertMichael Brown2024-01-161-0/+9
| | | | | | | Expose static_assert() via assert.h and migrate link-time assertions to build-time assertions where possible. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [eap] Add support for the MD5-Challenge authentication typeMichael Brown2024-01-101-0/+11
| | | | | | | | | RFC 3748 states that support for MD5-Challenge is mandatory for EAP implementations. The MD5 and CHAP code is already included in the default build since it is required by iSCSI, and so this does not substantially increase the binary size. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [eap] Add support for sending an EAP identityMichael Brown2024-01-101-5/+40
| | | | | | | | | | | | | Allow the ${netX/username} setting to be used to specify an EAP identity to be returned in response to a Request-Identity, and provide a mechanism for responding with a NAK to indicate which authentication types we support. If no identity is specified then fall back to the current behaviour of not sending any Request-Identity response, so that switches will time out and switch to MAC Authentication Bypass (MAB) if applicable. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [eap] Ignore any received EAP responsesMichael Brown2024-01-101-0/+3
| | | | | | | EAP responses (including our own) may be broadcast by switches but are not of interest to us and can be safely ignored if received. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [smbios] Support scanning for the 64-bit SMBIOS3 entry pointMichael Brown2023-12-291-0/+2
| | | | | | | | | | Support scanning for the 64-bit SMBIOS3 entry point in addition to the 32-bit SMBIOS2 entry point. Prefer use of the 32-bit entry point if present, since this is guaranteed to be within accessible memory. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Fix dependency list construction in EDK2 header import scriptMichael Brown2023-11-241-1/+1
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Update to current EDK2 headersMichael Brown2023-11-226-26/+65
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [eapol] Limit number of EAPoL-Start packets transmitted per attemptMichael Brown2023-11-071-0/+5
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [eapol] Delay EAPoL-Start while waiting for EAP to completeMichael Brown2023-11-071-3/+38
| | | | | | | | | | | | | | | | EAP exchanges may take a long time to reach a final status, especially when relying upon MAC Authentication Bypass (MAB). Our current behaviour of sending EAPoL-Start every few seconds until a final status is obtained can prevent these exchanges from ever completing. Fix by redefining the EAP supplicant state to allow EAPoL-Start to be suppressed: either temporarily (while waiting for a full EAP exchange to complete, in which case we need to eventually resend EAPoL-Start if the final Success or Failure packet is lost), or permanently (while waiting for the potentially very long MAC Authentication Bypass timeout period). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pci] Cache ECAM mapping errorsMichael Brown2023-11-021-0/+2
| | | | | | | | | When an error occurs during ECAM configuration space mapping, preserve the error within the existing cached mapping (instead of invalidating the cached mapping) in order to avoid flooding the debug log with repeated identical mapping errors. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [eapol] Send EAPoL-Start packets to trigger EAP authenticationsupplicantMichael Brown2023-09-191-0/+8
| | | | | | | | | | | | | | | | | | | | | | We have no way to force a link-layer restart in iPXE, and therefore no way to explicitly trigger a restart of EAP authentication. If an iPXE script has performed some action that requires such a restart (e.g. registering a device such that the port VLAN assignment will be changed), then the only means currently available to effect the restart is to reboot the whole system. If iPXE is taking over a physical link already used by a preceding bootloader, then even a reboot may not work. In the EAP model, the supplicant is a pure responder and never initiates transmissions. EAPoL extends this to include an EAPoL-Start packet type that may be sent by the supplicant to (re)trigger EAP. Add support for sending EAPoL-Start packets at two-second intervals on links that are open and have reached physical link-up, but for which EAP has not yet completed. This allows "ifclose ; ifopen" to be used to restart the EAP process. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [eap] Define a supplicant model for EAP and EAPoLMichael Brown2023-09-182-4/+30
| | | | | | | | Extend the EAP model to include a record of whether or not EAP authentication has completed (successfully or otherwise), and to provide a method for transmitting EAP responses. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [netdevice] Allocate private data for each network upper-layer driverMichael Brown2023-09-131-3/+10
| | | | | | | | | | | | | | | | | Allow network upper-layer drivers (such as LLDP, which attaches to each network device in order to provide a corresponding LLDP settings block) to specify a size for private data, which will be allocated as part of the network device structure (as with the existing private data allocated for the underlying device driver). This will allow network upper-layer drivers to be simplified by omitting memory allocation and freeing code. If the upper-layer driver requires a reference counter (e.g. for interface initialisation), then it may use the network device's existing reference counter, since this is now the reference counter for the containing block of memory. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [netdevice] Remove netdev_priv() helper functionMichael Brown2023-09-131-11/+0
| | | | | | | | | | Some network device drivers use the trivial netdev_priv() helper function while others use the netdev->priv pointer directly. Standardise on direct use of netdev->priv, in order to free up the function name netdev_priv() for reuse. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [ntp] Define NTP server settingMichael Brown2023-07-191-0/+3
| | | | | | | | | | | Define the IPv4 NTP server setting to simplify the use of a DHCP-provided NTP server in scripts, using e.g. #!ipxe dhcp ntp ${ntp} Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [console] Restore compatibility with "--key" values in existing scriptsMichael Brown2023-07-072-2/+17
| | | | | | | | | | | | | | | | Commit 3ef4f7e ("[console] Avoid overlap between special keys and Unicode characters") renumbered the special key encoding to avoid collisions with Unicode key values outside the ASCII range. This change broke backwards compatibility with existing scripts that specify key values using e.g. "prompt --key" or "menu --key". Restore compatibility with existing scripts by tweaking the special key encoding so that the relative key value (i.e. the delta from KEY_MIN) is numerically equal to the old pre-Unicode key value, and by modifying parse_key() to accept a relative key value. Reported-by: Sven Dreyer <sven@dreyer-net.de> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [interface] Fix debug message values for temporary interfacestmpintfMichael Brown2023-07-041-16/+56
| | | | | | | | | | | | | | | The interface debug message values constructed by INTF_DBG() et al rely on the interface being embedded within a containing object. This assumption is not valid for the temporary outbound-only interfaces constructed on the stack by intf_shutdown() and xfer_vredirect(). Formalise the notion of a temporary outbound-only interface as having a NULL interface descriptor, and overload the "original interface descriptor" field to contain a pointer to the original interface that the temporary interface is shadowing. Originally-fixed-by: Vincent Fazio <vfazio@gmail.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [console] Avoid overlap between special keys and Unicode charactersMichael Brown2023-07-041-5/+40
| | | | | | | | | | | | | | The special key range (from KEY_MIN upwards) currently overlaps with the valid range for Unicode characters, and therefore prohibits the use of Unicode key values outside the ASCII range. Create space for Unicode key values by moving the special keys to the range immediately above the maximum valid Unicode character. This allows the existing encoding of special keys as an efficiently packed representation of the equivalent ANSI escape sequence to be maintained almost as-is. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [console] Avoid overlap between remapping flags and character valuesMichael Brown2023-07-041-4/+4
| | | | | | | | | | | | | | | | | | | The keyboard remapping flags currently occupy bits 8 and upwards of the to-be-mapped character value. This overlaps the range used for special keys (KEY_MIN and upwards) and also overlaps the valid Unicode character range. No conflict is created by this overlap, since by design only ASCII character values (as generated by an ASCII-only keyboard driver) are subject to remapping, and so the to-be-remapped character values exist in a conceptually separate namespace from either special keys or non-ASCII Unicode characters. However, the overlap is potentially confusing for readers of the code. Minimise cognitive load by using bits 24 and upwards for the keyboard remapping flags. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [ioapi] Centralise definitions for dummy PIOMichael Brown2023-06-291-0/+64
| | | | | | | | | | There is no common standard for I/O-space access for non-x86 CPU families, and non-MMIO peripherals are vanishingly rare. Generalise the existing ARM definitions for dummy PIO to allow for reuse by other CPU architectures. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Provide read-only access to EFI variables via settings mechanismMichael Brown2023-06-091-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | EFI variables do not map neatly to the iPXE settings mechanism, since the EFI variable identifier includes a namespace GUID that cannot cleanly be supplied as part of a setting name. Creating a new EFI variable requires the variable's attributes to be specified, which does not fit within iPXE's settings concept. However, EFI variable names are generally unique even without the namespace GUID, and EFI does provide a mechanism to iterate over all existent variables. We can therefore provide read-only access to EFI variables by comparing only the names and ignoring the namespace GUIDs. Provide an "efi" settings block that implements this mechanism using a syntax such as: echo Platform language is ${efi/PlatformLang:string} show efi/SecureBoot:int8 Settings are returned as raw binary values by default since an EFI variable may contain boolean flags, integer values, ASCII strings, UCS-2 strings, EFI device paths, X.509 certificates, or any other arbitrary blob of data. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Include protocol interface address in debug outputMichael Brown2023-06-081-0/+13
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Add HTTP header and GUID definitionsMichael Brown2023-06-072-0/+518
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Add DNS headers and GUID definitionsMichael Brown2023-06-073-0/+1077
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Add Ip4Config2 header and GUID definitionMichael Brown2023-06-072-0/+319
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Add IPv6 versions of existing IPv4 headers and GUID definitionsMichael Brown2023-06-077-0/+4364
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Update to current EDK2 headersMichael Brown2023-06-078-40/+266
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Disable static assertions in EFI headers on non-EFI platformsMichael Brown2023-06-071-0/+9
| | | | | | | | | | | | | The EDK2 headers may be included even in builds for non-EFI platforms. Commits such as 9de6c45 ("[arm] Use -fno-short-enums for all 32-bit ARM builds") have so far ensured that the compile-time checks within the EDK2 headers will pass even when building for a non-EFI platform. As a more general solution, temporarily disable static assertions while including UefiBaseType.h if building on a non-EFI platform. This avoids the need to modify the ABI on other platforms. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Add support for PKCS#8 private key formatMichael Brown2023-06-021-0/+2
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Support versions of shim that perform SBAT verificationMichael Brown2023-05-232-1/+3
| | | | | | | | | | | | | | | The UEFI shim implements a fairly nicely designed revocation mechanism designed around the concept of security generations. Unfortunately nobody in the shim community has thus far added the relevant metadata to the Linux kernel, with the result that current versions of shim are incapable of booting current versions of the Linux kernel. Experience shows that there is unfortunately no point in trying to get a fix for this upstreamed into shim. We therefore default to working around this undesirable behaviour by patching data read from the "SbatLevel" variable used to hold SBAT configuration. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Add support for executing images via a shimMichael Brown2023-05-225-0/+76
| | | | | | | | | | | | | | | | | | | | | | | Add support for using a shim as a helper to execute an EFI image. When a shim has been specified via shim(), the shim image will be passed to LoadImage() instead of the selected EFI image and the command line will be prepended with the name of the selected EFI image. The selected EFI image will be accessible to the shim via the virtual filesystem as a hidden file. Reduce the Secure Boot attack surface by removing, where possible, the spurious requirement for a third party second stage loader binary such as GRUB to be used solely in order to call the "shim lock protocol" entry point. Do not install the EFI PXE APIs when using a shim, since if shim finds EFI_PXE_BASE_CODE_PROTOCOL on the loaded image's device handle then it will attempt to download files afresh instead of using the files already downloaded by iPXE and exposed via the EFI_SIMPLE_FILE_SYSTEM protocol. (Experience shows that there is no point in trying to get a fix for this upstreamed into shim.) Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Add definitions for the UEFI shim lock protocolMichael Brown2023-05-222-0/+32
| | | | | | | | | The UEFI shim includes a "shim lock protocol" that can be used by a third party second stage loader such as GRUB to verify a kernel image. Add definitions for the relevant portions of this protocol interface. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Add efi_asprintf() and efi_vasprintf()Michael Brown2023-05-222-0/+3
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [image] Generalise concept of selected imageMichael Brown2023-05-171-10/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Most image flags are independent values: any combination of flags may be set for any image, and the flags for one image are independent of the flags for any other image. The "selected" flag does not follow this pattern: at most one image may be marked as selected at any time. When invoking a kernel via the UEFI shim, there will be multiple "special" images: the selected kernel itself, the shim image, and potentially a shim-signed GRUB binary to be used as a crutch to assist shim in loading the kernel (since current versions of the UEFI shim are not capable of directly loading a Linux kernel). Remove the "selected" image flag and replace it with a general concept of an image tag with the same semantics: a given tag may be assigned to at most one image, an image may be found by its tag only while the image is currently registered, and a tag will survive unregistration and reregistration of an image (if it has not already been assigned to a new image). For visual consistency, also replace the current image pointer with a current image tag. The image pointer stored within the image tag holds only a weak reference to the image, since the selection of an image should not prevent that image from being freed. (The strong reference to the currently executing image is held locally within the execution scope of image_exec(), and is logically separate from the current image pointer.) Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [image] Allow for images to be hidden from lists of all imagesMichael Brown2023-05-051-9/+3
| | | | | | | | | | | | | | | When invoking a kernel via the UEFI shim, the kernel (and potentially also a helper binary such as GRUB) must be accessible via the virtual filesystem exposed via EFI_SIMPLE_FILE_SYSTEM_PROTOCOL but must not be present in the magic initrd constructed from all registered images. Allow for images to be flagged as hidden, which will cause them to be excluded from API-level lists of all images such as the virtual filesystem directory contents, the magic initrd, or the Multiboot module list. Hidden images remain visible to iPXE commands including "imgstat", which will show a "[HIDDEN]" flag for such images. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [tls] Handle fragmented handshake recordsMichael Brown2023-03-301-0/+2
| | | | | Originally-implemented-by: Christopher Schenk <christopher@cschenk.net> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [tls] Clean up change cipher spec record handlingMichael Brown2023-03-301-0/+3
| | | | | | | Define and use data structures and constants for the (single-byte) change cipher spec records. Signed-off-by: Michael Brown <mcb30@ipxe.org>
generated by cgit (git 2.34.1) at 2025-02-23 23:43:14 +0000