aboutsummaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* [pci] Backup and restore standard config space across PCIe FLRflrMichael Brown2022-11-131-2/+7
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pci] Allow PCI config space backup to be limited by maximum offsetMichael Brown2022-11-135-13/+22
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [tls] Add GCM cipher suitesMichael Brown2022-11-107-8/+147
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [tests] Verify ability to perform in-place encryption and decryptionMichael Brown2022-11-101-4/+6
| | | | | | | | | | TLS relies upon the ability of ciphers to perform in-place decryption, in order to avoid allocating additional I/O buffers for received data. Add verification of in-place encryption and decryption to the cipher self-tests. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Support in-place decryption for GCM ciphersMichael Brown2022-11-101-34/+32
| | | | | | | | | | | | The hash calculation is currently performed incorrectly when decrypting in place, since the ciphertext will have been overwritten with the plaintext before being used to update the hash value. Restructure the code to allow for in-place encryption and decryption. Choose to optimise for the decryption case, since we are likely to decrypt much more data than we encrypt. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [tests] Verify ability to reset cipher initialisation vectorMichael Brown2022-11-091-0/+38
| | | | | | | | | | TLS relies upon the ability to reuse a cipher by resetting only the initialisation vector while reusing the existing key. Add verification of resetting the initialisation vector to the cipher self-tests. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Ensure relevant GCM cipher state is cleared by cipher_setiv()Michael Brown2022-11-092-11/+17
| | | | | | | Reset the accumulated authentication state when cipher_setiv() is called, to allow the cipher to be reused without resetting the key. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [tls] Allow handshake digest algorithm to be specified by cipher suiteMichael Brown2022-11-094-68/+125
| | | | | | | | | | | | | | | | | | | All existing cipher suites use SHA-256 as the TLSv1.2 and above handshake digest algorithm (even when using SHA-1 as the MAC digest algorithm). Some GCM cipher suites use SHA-384 as the handshake digest algorithm. Allow the cipher suite to specify the handshake (and PRF) digest algorithm to be used for TLSv1.2 and above. This requires some restructuring to allow for the fact that the ClientHello message must be included within the handshake digest, even though the relevant digest algorithm is not yet known at the point that the ClientHello is sent. Fortunately, the ClientHello may be reproduced verbatim at the point of receiving the ServerHello, so we rely on reconstructing (rather than storing) this message. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [tls] Always send maximum supported version in ClientHelloMichael Brown2022-11-091-1/+1
| | | | | | | | | | | | Always send the maximum supported version in our ClientHello message, even when performing renegotiation (in which case the current version may already be lower than the maximum supported version). This is permitted by the specification, and allows the ClientHello to be reconstructed verbatim at the point of selecting the handshake digest algorithm in tls_new_server_hello(). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [tls] Add support for AEAD ciphersMichael Brown2022-11-081-2/+39
| | | | | | | | Allow for AEAD cipher suites where the MAC length may be zero and the authentication is instead provided by an authenticating cipher, with the plaintext authentication tag appended to the ciphertext. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [tls] Treat invalid block padding as zero length paddingMichael Brown2022-11-081-2/+2
| | | | | | | | Harden against padding oracle attacks by treating invalid block padding as zero length padding, thereby deferring the failure until after computing the (incorrect) MAC. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [tls] Allow for arbitrary-length initialisation vectorsMichael Brown2022-11-082-186/+148
| | | | | | | | | Restructure the encryption and decryption operations to allow for the use of ciphers where the initialisation vector is constructed by concatenating the fixed IV (derived as part of key expansion) with a record IV (prepended to the ciphertext). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [tls] Add MAC length as a cipher suite parameterMichael Brown2022-11-084-16/+28
| | | | | | | | | | | | | | | TLS stream and block ciphers use a MAC with a length equal to the output length of the digest algorithm in use. For AEAD ciphers there is no MAC, with the equivalent functionality provided by the cipher algorithm's authentication tag. Allow for the existence of AEAD cipher suites by making the MAC length a parameter of the cipher suite. Assume that the MAC key length is equal to the MAC length, since this is true for all currently supported cipher suites. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [tls] Abstract out concept of a TLS authentication headerMichael Brown2022-11-082-21/+27
| | | | | | | | | | | | | All TLS cipher types use a common structure for the per-record data that is authenticated in addition to the plaintext itself. This data is used as a prefix in the HMAC calculation for stream and block ciphers, or as additional authenticated data for AEAD ciphers. Define a "TLS authentication header" structure to hold this data as a contiguous block, in order to meet the alignment requirement for AEAD ciphers such as GCM. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [tls] Ensure cipher alignment size is respectedMichael Brown2022-11-071-0/+18
| | | | | | | | Adjust the length of the first received ciphertext data buffer to ensure that all decryption operations respect the cipher's alignment size. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Add concept of cipher alignment sizeMichael Brown2022-11-078-1/+33
| | | | | | | | | | | | | | | | | | | The GCM cipher mode of operation (in common with other counter-based modes of operation) has a notion of blocksize that does not neatly fall into our current abstraction: it does operate in 16-byte blocks but allows for an arbitrary overall data length (i.e. the final block may be incomplete). Model this by adding a concept of alignment size. Each call to encrypt() or decrypt() must begin at a multiple of the alignment size from the start of the data stream. This allows us to model GCM by using a block size of 1 byte and an alignment size of 16 bytes. As a side benefit, this same concept allows us to neatly model the fact that raw AES can encrypt only a single 16-byte block, by specifying an alignment size of zero on this cipher. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [tls] Formalise notions of fixed and record initialisation vectorsMichael Brown2022-11-074-5/+48
| | | | | | | | | | | | | | | | | | | | | TLS block ciphers always use CBC (as per RFC 5246 section 6.2.3.2) with a record initialisation vector length that is equal to the cipher block size, and no fixed initialisation vector. The initialisation vector for AEAD ciphers such as GCM is less straightforward, and requires both a fixed and per-record component. Extend the definition of a cipher suite to include fixed and record initialisation vector lengths, and generate the fixed portion (if any) as part of key expansion. Do not add explicit calls to cipher_setiv() in tls_assemble_block() and tls_split_block(), since the constraints imposed by RFC 5246 are specifically chosen to allow implementations to avoid doing so. (Instead, add a sanity check that the record initialisation vector length is equal to the cipher block size.) Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [tls] Remove support for TLSv1.0Michael Brown2022-11-072-36/+6
| | | | | | | | | | | | | | | | The TLSv1.0 protocol was deprecated by RFC 8996 (along with TLSv1.1), and has been disabled by default in iPXE since commit dc785b0fb ("[tls] Default to supporting only TLSv1.1 or above") in June 2020. While there is value in continuing to support older protocols for interoperability with older server appliances, the additional complexity of supporting the implicit initialisation vector for TLSv1.0 is not worth the cost. Remove support for the obsolete TLSv1.0 protocol, to reduce complexity of the implementation and simplify ongoing maintenance. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Clear DMA-coherent buffers before mappingioactiveMichael Brown2022-11-041-0/+3
| | | | | | | | | | | | | | | | | | | The DMA mapping is performed implicitly as part of the call to dma_alloc(). The current implementation creates the IOMMU mapping for the allocated and potentially uninitialised data before returning to the caller (which will immediately zero out or otherwise initialise the buffer). This leaves a small window within which a malicious PCI device could potentially attempt to retrieve firmware-owned secrets present in the uninitialised buffer. (Note that the hypothetically malicious PCI device has no viable way to know the address of the buffer from which to attempt a DMA read, rendering the attack extremely implausible.) Guard against any such hypothetical attacks by zeroing out the allocated buffer prior to creating the coherent DMA mapping. Suggested-by: Mateusz Siwiec <Mateusz.Siwiec@ioactive.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [bzimage] Fix parsing of "vga=..." when not at end of command linevgafixMichael Brown2022-10-271-4/+10
| | | | | | | | | | | | bzimage_parse_cmdline() uses strcmp() to identify the named "vga=..." kernel command line option values, which will give a false negative if the option is not last on the command line. Fix by temporarily changing the relevant command line separator (if any) to a NUL terminator. Debugged-by: Simon Rettberg <simon.rettberg@rz.uni-freiburg.de> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Add block cipher Galois/Counter mode of operationMichael Brown2022-10-257-0/+1072
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Add concept of authentication tag to cipher algorithmsMichael Brown2022-10-259-7/+64
| | | | | | | | Some ciphers (such as GCM) support the concept of a tag that can be used to authenticate the encrypted data. Add a cipher method for generating an authentication tag. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Add concept of additional data to cipher algorithmsMichael Brown2022-10-254-23/+47
| | | | | | | | | | | Some ciphers (such as GCM) support the concept of additional authenticated data, which does not appear in the ciphertext but may affect the operation of the cipher. Allow cipher_encrypt() and cipher_decrypt() to be called with a NULL destination buffer in order to pass additional data. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Allow initialisation vector length to vary from cipher blocksizeMichael Brown2022-10-257-16/+24
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Expose null crypto algorithm methods for reuseMichael Brown2022-10-254-51/+54
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [tls] Add support for DHE variants of the existing cipher suitesMichael Brown2022-10-113-4/+56
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [tls] Add support for Ephemeral Diffie-Hellman key exchangeMichael Brown2022-10-112-0/+247
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [tls] Add key exchange mechanism to definition of cipher suiteMichael Brown2022-10-114-3/+48
| | | | | | | Allow for the key exchange mechanism to vary depending upon the selected cipher suite. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [tls] Record ServerKeyExchange record, if providedMichael Brown2022-10-112-0/+40
| | | | | | | Accept and record the ServerKeyExchange record, which is required for key exchange mechanisms such as Ephemeral Diffie-Hellman (DHE). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [tls] Generate pre-master secret at point of sending ClientKeyExchangeMichael Brown2022-10-112-26/+27
| | | | | | | | | | | | | | The pre-master secret is currently constructed at the time of instantiating the TLS connection. This precludes the use of key exchange mechanisms such as Ephemeral Diffie-Hellman (DHE), which require a ServerKeyExchange message to exchange additional key material before the pre-master secret can be constructed. Allow for the use of such cipher suites by deferring generation of the master secret until the point of sending the ClientKeyExchange message. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [tls] Generate master secret at point of sending ClientKeyExchangeMichael Brown2022-10-111-8/+13
| | | | | | | | | | | | | | The master secret is currently constructed upon receiving the ServerHello message. This precludes the use of key exchange mechanisms such as Ephemeral Diffie-Hellman (DHE), which require a ServerKeyExchange message to exchange additional key material before the pre-master secret and master secret can be constructed. Allow for the use of such cipher suites by deferring generation of the master secret until the point of sending the ClientKeyExchange message. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Add Ephemeral Diffie-Hellman key exchange algorithmMichael Brown2022-10-115-0/+936
| | | | | | | | Add an implementation of the Ephemeral Diffie-Hellman key exchange algorithm as defined in RFC2631, with test vectors taken from the NIST Cryptographic Toolkit. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Simplify internal HMAC APIMichael Brown2022-10-1016-163/+142
| | | | | | | | | | | | Simplify the internal HMAC API so that the key is provided only at the point of calling hmac_init(), and the (potentially reduced) key is stored as part of the context for later use by hmac_final(). This simplifies the calling code, and avoids the need for callers such as TLS to allocate a potentially variable length block in order to retain a copy of the unmodified key. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [test] Add HMAC self-testsMichael Brown2022-10-102-0/+212
| | | | | | | | | | | | The HMAC code is already tested indirectly via several consuming algorithms that themselves provide self-tests (e.g. HMAC-DRBG, NTLM authentication, and PeerDist content identification), but lacks any direct test vectors. Add explicit HMAC tests and ensure that corner cases such as empty keys, block-length keys, and over-length keys are all covered. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [ena] Assign memory BAR if left empty by BIOSMichael Brown2022-09-191-0/+45
| | | | | | | | | | | | | | | Some BIOSes in AWS EC2 (observed with a c6i.metal instance in eu-west-2) will fail to assign an MMIO address to the ENA device, which causes ioremap() to fail. Experiments show that the ENA device is the only device behind its bridge, even when multiple ENA devices are present, and that the BIOS does assign a memory window to the bridge. We may therefore choose to assign the device an MMIO address at the start of the bridge's memory window. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pci] Add minimal PCI bridge driverMichael Brown2022-09-194-0/+191
| | | | | | | Add a minimal driver for PCI bridges that can be used to locate the bridge to which a PCI device is attached. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pci] Select PCI I/O API at runtime for cloud imagesMichael Brown2022-09-1811-1/+256
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pretty much all physical machines and off-the-shelf virtual machines will provide a functional PCI BIOS. We therefore default to using only the PCI BIOS, with no fallback to an alternative mechanism if the PCI BIOS fails. AWS EC2 provides the opportunity to experience some exceptions to this rule. For example, the t3a.nano instances in eu-west-1 have no functional PCI BIOS at all. As of commit 83516ba ("[cloud] Use PCIAPI_DIRECT for cloud images") we therefore use direct Type 1 configuration space accesses in the images built and published for use in the cloud. Recent experience has discovered yet more variation in AWS EC2 instances. For example, some of the metal instance types have multiple PCI host bridges and the direct Type 1 accesses therefore see only a subset of the PCI devices. Attempt to accommodate future such variations by making the PCI I/O API selectable at runtime and choosing ECAM (if available), falling back to the PCI BIOS (if available), then finally falling back to direct Type 1 accesses. This is implemented as a dedicated PCIAPI_CLOUD API, rather than by having the PCI core select a suitable API at runtime (as was done for timers in commit 302f1ee ("[time] Allow timer to be selected at runtime"). The common case will remain that only the PCI BIOS API is required, and we would prefer to retain the optimisations that come from inlining the configuration space accesses in this common case. Cloud images are (at present) disk images rather than ROM images, and so the increased code size required for this design approach in the PCIAPI_CLOUD case is acceptable. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [bios] Allow pcibios_discover() to return an empty rangeMichael Brown2022-09-181-3/+5
| | | | | | | Allow pcibios_discover() to return an empty range if the INT 1A,B101 PCI BIOS installation check call fails. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pci] Add support for the Enhanced Configuration Access Mechanism (ECAM)Michael Brown2022-09-165-0/+461
| | | | | | | | | | | | | The ACPI MCFG table describes a direct mapping of PCI configuration space into MMIO space. This mapping allows access to extended configuration space (up to 4096 bytes) and also provides for the existence of multiple host bridges. Add support for the ECAM mechanism described by the ACPI MCFG table, as a selectable PCI I/O API alongside the existing PCI BIOS and Type 1 mechanisms. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pci] Generalise pci_num_bus() to pci_discover()Michael Brown2022-09-1510-43/+78
| | | | | | | | | | Allow pci_find_next() to discover devices beyond the first PCI segment, by generalising pci_num_bus() (which implicitly assumes that there is only a single PCI segment) with pci_discover() (which has the ability to return an arbitrary contiguous chunk of PCI bus:dev.fn address space). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pci] Check for wraparound in callers of pci_find_next()Michael Brown2022-09-153-3/+10
| | | | | | | | | | | | | | | | The semantics of the bus:dev.fn parameter passed to pci_find_next() are "find the first existent PCI device at this address or higher", with the caller expected to increment the address between finding devices. This does not allow the parameter to distinguish between the two cases "start from address zero" and "wrapped after incrementing maximal possible address", which could therefore lead to an infinite loop in the degenerate case that a device with address ffff:ff:1f.7 really exists. Fix by checking for wraparound in the caller (which is already responsible for performing the increment). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pci] Allow pci_find_next() to return non-zero PCI segmentsMichael Brown2022-09-153-16/+14
| | | | | | | | Separate the return status code from the returned PCI bus:dev.fn address, in order to allow pci_find_next() to be used to find devices with a non-zero PCI segment number. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [linux] Add missing PROVIDE_PCIAPI_INLINE() macrosMichael Brown2022-09-151-0/+9
| | | | | | | Ensure type consistency of the PCI I/O API methods by adding the missing PROVIDE_PCIAPI_INLINE() macros. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [ipv6] Ignore SLAAC on prefixes with an incompatible prefix lengthMichael Brown2022-09-131-11/+25
| | | | | | | | | | | | | Experience suggests that routers are often misconfigured to advertise SLAAC even on prefixes that do not have a SLAAC-compatible prefix length. iPXE will currently treat this as an error, resulting in the prefix being ignored completely. Handle this misconfiguration by ignoring the autonomous address flag when the prefix length is unsuitable for SLAAC. Reported-by: Malte Janduda <mail@janduda.net> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [ipv6] Fix mask calculation when prefix length is not a multiple of 8Michael Brown2022-09-062-1/+38
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [test] Validate constructed IPv6 routing table entriesMichael Brown2022-09-061-12/+52
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [ena] Increase receive ring size to 128 entriesMichael Brown2022-08-262-5/+12
| | | | | | | | | | | | | | Some versions of the ENA hardware (observed on a c6i.large instance in eu-west-2) seem to require a receive ring containing at least 128 entries: any smaller ring will never see receive completions or will stall after the first few completions. Increase the receive ring size to 128 entries (determined empirically) for compatibility with these hardware versions. Limit the receive ring fill level to 16 (as at present) to avoid consuming more memory than will typically be available in the internal heap. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [ena] Provide a host information pageMichael Brown2022-08-262-0/+159
| | | | | | | | | | | | | | | | | | | | | | Some versions of the ENA firmware (observed on a c6i.large instance in eu-west-2) seem to require a host information page, without which the CREATE_CQ command will fail with ENA_ADMIN_UNKNOWN_ERROR. These firmware versions also seem to require us to claim that we are a Linux kernel with a specific driver major version number. This appears to be a firmware bug, as revealed by Linux kernel commit 1a63443af ("net/amazon: Ensure that driver version is aligned to the linux kernel"): this commit changed the value of the driver version number field to be the Linux kernel version, and was hastily reverted in commit 92040c6da ("net: ena: fix broken interface between ENA driver and FW") which clarified that the version number field does actually have some undocumented significance to some versions of the firmware. Fix by providing a host information page via the SET_FEATURE command, incorporating the apparently necessary lies about our identity. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [ena] Specify the unused completion queue MSI-X vector as 0xffffffffMichael Brown2022-08-262-0/+9
| | | | | | | | | | | | Some versions of the ENA firmware (observed on a c6i.large instance in eu-west-2) will complain if the completion queue's MSI-X vector field is left empty, even though the queue configuration specifies that interrupts are not used. Work around these firmware versions by passing in what appears to be the magic "no MSI-X vector" value in this field. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [ena] Allow for out-of-order completionsMichael Brown2022-08-262-20/+62
| | | | | | | | | | | | | | | | | | | | | | The ENA data path design has separate submission and completion queues. Submission queues must be refilled in strict order (since there is only a single linear tail pointer used to communicate the existence of new entries to the hardware), and completion queue entries include a request identifier copied verbatim from the submission queue entry. Once the submission queue doorbell has been rung, software never again reads from the submission queue entry and nothing ever needs to write back to the submission queue entry since completions are reported via the separate completion queue. This design allows the hardware to complete submission queue entries out of order, provided that it internally caches at least as many entries as it leaves gaps. Record and identify I/O buffers by request identifier (using a circular ring buffer of unique request identifiers), and remove the assumption that submission queue entries will be completed in order. Signed-off-by: Michael Brown <mcb30@ipxe.org>
generated by cgit (git 2.34.1) at 2025-02-23 04:20:20 +0000