aboutsummaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
...
* [tls] Add support for Ephemeral Elliptic Curve Diffie-Hellman key exchangeMichael Brown2024-01-302-0/+193
| | | | | | | Add support for the Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) key exchange algorithm. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [tls] Split out Diffie-Hellman parameter signature verificationMichael Brown2024-01-301-39/+62
| | | | | | | | | | | DHE and ECDHE use essentially the same mechanism for verifying the signature over the Diffie-Hellman parameters, though the format of the parameters is different between the two methods. Split out the verification of the parameter signature so that it may be shared between the DHE and ECDHE key exchange algorithms. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [tls] Generate key material after sending ClientKeyExchangeMichael Brown2024-01-301-16/+15
| | | | | | | | | | | | | The construction of the key material for the pending cipher suites from the TLS master secret must happen regardless of which key exchange algorithm is in use, and the key material is not required to send the ClientKeyExchange handshake (which is sent before changing cipher suites). Centralise the call to tls_generate_keys() after performing key exchange via the selected algorithm. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [tls] Restructure construction of ClientHello messageMichael Brown2024-01-301-72/+99
| | | | | | | | | Define an individual local structure for each extension and a single structure for the list of extensions. This makes it viable to add extensions such as the Supported Elliptic Curves extension, which must not be present if the list of curves is empty. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Add an abstraction of an elliptic curveMichael Brown2024-01-303-0/+57
| | | | | | | 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-304-12/+47
| | | | | | | | | | | | | 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>
* [bnxt] Add support for additional chip IDsJoseph Wong2024-01-192-2/+6
| | | | | | | Add additional chip IDs that can be recognized as part of the thor family. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Add X25519 key exchange algorithmMichael Brown2024-01-194-0/+1471
| | | | | | | | | | | | | | | | | 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>
* [loong64] Replace broken big integer arithmetic implementationsMichael Brown2024-01-192-78/+115
| | | | | | | | | | | | | The slightly incomprehensible LoongArch64 implementation for bigint_subtract() is observed to produce incorrect results for some input values. Replace the suspicious LoongArch64 implementations of bigint_add(), bigint_subtract(), bigint_rol() and bigint_ror(), and add a test case for a subtraction that was producing an incorrect result with the previous implementation. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Add bigint_swap() to conditionally swap big integersMichael Brown2024-01-193-0/+94
| | | | | | | 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-192-0/+23
| | | | | | | | | | | 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-1610-68/+103
| | | | | | | | | | | 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-1612-87/+78
| | | | | | | | | | | | | | | | | | | | | | | 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-165-7/+15
| | | | | | | 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>
* [build] Fix building with newer binutilsMichael Brown2024-01-1424-19/+22
| | | | | | | | | | | | | | | | | Newer versions of the GNU assembler (observed with binutils 2.41) will complain about the ".arch i386" in files assembled with "as --64", with the message "Error: 64bit mode not supported on 'i386'". In files such as stack.S that contain no instructions to be assembled, the ".arch i386" is redundant and may be removed entirely. In the remaining files, fix by moving ".arch i386" below the relevant ".code16" or ".code32" directive, so that the assembler is no longer expecting 64-bit instructions to be used by the time that the ".arch i386" directive is encountered. Reported-by: Ali Mustakim <alim@forwardcomputers.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Remove unnecessary ".text" directivesMichael Brown2024-01-1421-21/+0
| | | | | | | | | The .text directive is entirely redundant when followed by a .section directive giving an explicit section name and attributes. Remove these unnecessary directives to simplify the code. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [eap] Add support for the MD5-Challenge authentication typeMichael Brown2024-01-102-0/+91
| | | | | | | | | 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-102-25/+177
| | | | | | | | | | | | | 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-102-0/+6
| | | | | | | 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>
* [build] Reduce scope of wildcard .gitignore rulesMark Rogalski2024-01-093-1/+3
| | | | | | | | Ensure that .gitignore rules do not cover any files that do exist within the repository. Modified-by: Michael Brown <mcb30@ipxe.org> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [smbios] Support scanning for the 64-bit SMBIOS3 entry pointMichael Brown2023-12-293-15/+120
| | | | | | | | | | 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>
* [intel] Add PCI ID for I219-LM (23)Christian Helmuth2023-12-211-0/+1
| | | | | | Successfully tested on FUJITSU LIFEBOOK U7413. Signed-off-by: Christian Helmuth <christian.helmuth@genode-labs.com>
* [efi] Add potentially missing relocation typesMichael Brown2023-12-211-0/+9
| | | | | | | | | | Add definitions for relocation types that may be missing on older versions of the host system's elf.h. This mirrors wimboot commit 47f6298 ("[efi] Add potentially missing relocation types"). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Fix Coverity warning about unintended sign extensionMichael Brown2023-12-191-2/+2
| | | | | | | | | | | | | | | The result of multiplying a uint16_t by another uint16_t will be a signed int. Comparing this against a size_t will perform an unwanted sign extension. Fix by explicitly casting e_phnum to an unsigned int, thereby matching the data type used for the loop index variable (and avoiding the unwanted sign extension). This mirrors wimboot commit 15f6162 ("[efi] Fix Coverity warning about unintended sign extension"). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Add relocation types generated by clangMichael Brown2023-12-191-0/+3
| | | | | | | | | | Add additional PC-relative relocation types that may be encountered when converting binaries compiled with clang. This mirrors the relevant elf2efi portions of wimboot commit 7910830 ("[build] Support building with the clang compiler"). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Use SOURCE_DATE_EPOCH for FAT serial number if it existsMichael Brown2023-12-191-0/+4
| | | | | Reported-by: Bernhard M. Wiedemann <bwiedemann@suse.de> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Allow compiling elf2efi with clangMichael Brown2023-12-051-1/+1
| | | | | | | | | | | | | The clang compiler does not (and apparently will not ever) allow for variable-length arrays within structs. Work around this limitation by using a fixed-length array to hold the PDB filename in the debug section. This mirrors wimboot commit f52c3ff ("[efi] Allow compiling elf2efi with clang"). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Avoid modifying PE/COFF debug filenameMichael Brown2023-11-291-2/+2
| | | | | | | | | | | | | The function efi_pecoff_debug_name() (called by efi_handle_name()) is used to extract a filename from the debug data directory entry located within a PE/COFF image. The name is copied into a temporary static buffer to allow for modifications, but the code currently erroneously modifies the original name within the loaded PE/COFF image. Fix by performing the modification on the copy in the temporary buffer, as originally intended. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Extend PE header size to cover space up to first sectionMichael Brown2023-11-271-2/+23
| | | | | | | | | | | | | | Hybrid bzImage and UEFI binaries (such as wimboot) may place sections at explicit offsets within the PE file, as described in commit b30a098 ("[efi] Use load memory address as file offset for hybrid binaries"). This can leave a gap after the PE headers that is not covered by any section. It is not entirely clear whether or not such gaps are permitted in binaries submitted for Secure Boot signing. To minimise potential problems, extend the PE header size to cover any space before the first explicitly placed section. 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] Maximise image base addressMichael Brown2023-11-241-0/+44
| | | | | | | | | | | | iPXE images are linked with a starting virtual address of zero. Other images (such as wimboot) may use a non-zero starting virtual address. There is no direct equivalent of the PE ImageBase address field within ELF object files. Choose to use the highest possible address that accommodates all sections and the PE header itself, since this will minimise the memory allocated to hold the loaded image. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Do not assume canonical PE section orderingMichael Brown2023-11-241-56/+37
| | | | | | | | | | | | The BaseOfCode (and, in PE32, BaseOfData) fields imply an assumption that binaries are laid out as code followed by initialised data followed by uninitialised data. This assumption may not be valid for complex binaries such as wimboot. Remove this implicit assumption, and use arguably justifiable values for the assorted summary start and size fields within the PE headers. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Treat 16-bit sections as hidden in hybrid binariesMichael Brown2023-11-241-0/+6
| | | | | | | | Hybrid bzImage and UEFI binaries (such as wimboot) may include 16-bit sections such as .bss16 that do not need to consume an entry in the PE section list. Treat any such sections as hidden. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Place PE debug information in a hidden sectionMichael Brown2023-11-231-31/+15
| | | | | | | | | | | | | The PE debug information generated by elf2efi is used only to hold the image filename, and the debug information is located via the relevant data directory entry rather than via the section table. Make the .debug section a hidden section in order to save one entry in the PE section list. Choose to place the debug information in the unused space at the end of the PE headers, since it no longer needs to satisfy the general section alignment constraints. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Fix recorded overall size of headers in NT optional headerMichael Brown2023-11-231-1/+6
| | | | | | | | | | | | | Commit 1e4c378 ("[efi] Shrink size of data directory in PE header") reduced the number of entries used in the data directory and reduced the recorded size of the NT "optional" header, but did not also adjust the recorded overall size of the PE headers, resulting in unused space between the PE headers and the first section. Fix by reducing the initial recorded size of the PE headers by the size of the omitted data directory entries. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Write out PE header only after writing sectionsMichael Brown2023-11-231-22/+28
| | | | | | | | | | | | Hybrid bzImage and UEFI binaries (such as wimboot) include a bzImage header within a section starting at offset zero, with the PE header effectively occupying unused space within this section. Allow for this by treating a section placed at offset zero as hidden, and by deferring the writing of the PE header until after the output sections have been written. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Use load memory address as file offset for hybrid binariesMichael Brown2023-11-231-7/+77
| | | | | | | | | | | | | Hybrid bzImage and UEFI binaries (such as wimboot) may be loaded as a single contiguous blob without reference to the PE headers, and the placement of sections within the PE file must therefore be known at link time. Use the load memory address (extracted from the ELF program headers) to determine the physical placement of the section within the PE file when generating a hybrid binary. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Mark PE images as large address awareMichael Brown2023-11-231-0/+1
| | | | | | | | | | | | | The images generated by elf2efi can be loaded anywhere in the address space, and are not limited to the low 2GB. Indicate this by setting the "large address aware" flag within the PE header, for compatibility with EFI images generated by the EDK2 build process. (The EDK2 PE loader does not ever check this flag, and it is unlikely that any other EFI PE loader ever does so, but we may as well report it accurately.) Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Set NXCOMPAT bit in PE headerMichael Brown2023-11-231-0/+2
| | | | | | | Indicate that the binary is compatible with W^X protections by setting the NXCOMPAT bit in the DllCharacteristics field of the PE header. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Treat writable sections as data sectionsMichael Brown2023-11-231-11/+11
| | | | | | | | | | | | | | Hybrid bzImage and UEFI binaries (such as wimboot) may include 16-bit executable code that is opaque data from the perspective of a UEFI PE binary, as described in wimboot commit fe456ca ("[efi] Use separate .text and .data PE sections"). The ELF section will be marked as containing both executable code and writable data. Choose to treat such a section as a data section rather than a code section, since that matches the expected semantics for ELF files that we expect to process. 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>
* [cloud] Add utility script to read iPXE output from INT13CON partitionMichael Brown2023-11-071-0/+68
| | | | | | | | | | | | | | | | | | Some AWS instance types still do not support serial console output or screenshots. For these instance types, the only viable way to extract debugging information is to use the INT13 console (which is already enabled via CONFIG=cloud for all AWS images). Obtaining the INT13 console output can be very cumbersome, since there is no direct way to read from an AWS volume. The simplest current approach is to stop the instance under test, detach its root volume, and reattach the volume to a Linux instance in the same region. Add a utility script aws-int13con to retrieve the INT13 console output by creating a temporary snapshot, reading the first block from the snapshot, and extracting the INT13 console partition content. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [cloud] Add ability to overwrite existing AMI imagesMichael Brown2023-11-071-2/+13
| | | | | | | | AMI names must be unique within a region. Add a --overwrite option that allows an existing AMI of the same name to be deregistered (and its underlying snapshot deleted). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [eapol] Limit number of EAPoL-Start packets transmitted per attemptMichael Brown2023-11-072-0/+13
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [eapol] Delay EAPoL-Start while waiting for EAP to completeMichael Brown2023-11-073-44/+84
| | | | | | | | | | | | | | | | 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] Require discovery of a PCI device when determining usable PCI APIsMichael Brown2023-11-021-11/+14
| | | | | | | | | | | | | The PCI cloud API (PCIAPI_CLOUD) currently selects the first PCI API that successfully discovers a PCI device address range. The ECAM API may discover an address range but subsequently be unable to map the configuration space region, which would result in the selected PCI API being unusable. Fix by instead selecting the first PCI API that can be successfully used to discover a PCI device. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pci] Check that ECAM configuration space is within reachable memoryMichael Brown2023-11-021-0/+9
| | | | | | | | | | | | | | | | | Some machines (observed with an AWS EC2 m7a.large instance) will place the ECAM configuration space window above 4GB, thereby making it unreachable from non-paged 32-bit code. This problem is currently ignored by iPXE, since the address is silently truncated in the call to ioremap(). (Note that other uses of ioremap() are not affected since the PCI core will already have checked for unreachable 64-bit BARs when retrieving the physical address to be mapped.) Fix by adding an explicit check that the region to be mapped starts within the reachable memory address space. (Assume that no machines will be sufficiently peverse to provide a region that straddles the 4GB boundary.) Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pci] Cache ECAM mapping errorsMichael Brown2023-11-022-2/+6
| | | | | | | | | 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>
* [pci] Handle non-zero starting bus in ECAM allocationsMichael Brown2023-11-021-0/+1
| | | | | | | | | | | | | The base address provided in the PCI ECAM allocation within the ACPI MCFG table is the base address for the segment as a whole, not for the starting bus within that allocation. On machines that provide ECAM allocations with a non-zero starting bus number (observed with an AWS EC2 m7a.large instance), this will result in iPXE accessing the wrong memory addresses within the ECAM region. Fix by adding the appropriate starting bus offset to the base address. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pci] Force completion of ECAM configuration space writesMichael Brown2023-11-011-1/+10
| | | | | | | | | | | | | | | | | | | | | The PCIe specification requires that "processor and host bridge implementations must ensure that a method exists for the software to determine when the write using the ECAM is completed by the completer" but does not specify any particular method to be used. Some platforms might treat writes to the ECAM region as non-posted, others might require reading back from a dedicated (and implementation-specific) completion register to determine when the configuration space write has completed. Since PCI configuration space writes will never be used for any performance-critical datapath operations (on any sane hardware), a simple and platform-independent solution is to always read back from the written register in order to guarantee that the write must have completed. This is safe to do, since the PCIe specification defines a limited set of configuration register types, none of which have read side effects. Signed-off-by: Michael Brown <mcb30@ipxe.org>