aboutsummaryrefslogtreecommitdiffstats
path: root/src/include
Commit message (Collapse)AuthorAgeFilesLines
* [menu] Allow a post-activity timeout to be definedHEADmastercoverity_scanMichael Brown4 days1-1/+2
| | | | | | | | | Allow the "--retimeout" option to be used to specify a timeout value that will be (re)applied after each keypress activity. This allows script authors to ensure that a single (potentially accidental) keypress will not pause the boot process indefinitely. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Start up RBG on demand if neededrbgstartMichael Brown5 days1-19/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The ANS X9.82 specification implicitly assumes that the RBG_Startup function will be called before it is needed, and includes checks to make sure that Generate_function fails if this has not happened. However, there is no well-defined point at which the RBG_Startup function is to be called: it's just assumed that this happens as part of system startup. We currently call RBG_Startup to instantiate the DRBG as an iPXE startup function, with the corresponding shutdown function uninstantiating the DRBG. This works for most use cases, and avoids an otherwise unexpected user-visible delay when a caller first attempts to use the DRBG (e.g. by attempting an HTTPS download). The download of autoexec.ipxe for UEFI is triggered by the EFI root bus probe in efi_probe(). Both the root bus probe and the RBG startup function run at STARTUP_NORMAL, so there is no defined ordering between them. If the base URI for autoexec.ipxe uses HTTPS, then this may cause random bits to be requested before the RBG has been started. Extend the logic in rbg_generate() to automatically start up the RBG if startup has not already been attempted. If startup fails (e.g. because the entropy source is broken), then do not automatically retry since this could result in extremely long delays waiting for entropy that will never arrive. Reported-by: Michael Niehaus <niehaus@live.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Support direct reduction only for Montgomery constant R^2 mod NMichael Brown9 days1-21/+64
| | | | | | | | | | | | | | | | | | | | | | The only remaining use case for direct reduction (outside of the unit tests) is in calculating the constant R^2 mod N used during Montgomery multiplication. The current implementation of direct reduction requires a writable copy of the modulus (to allow for shifting), and both the modulus and the result buffer must be padded to be large enough to hold (R^2 - N), which is twice the size of the actual values involved. For the special case of reducing R^2 mod N (or any power of two mod N), we can run the same algorithm without needing either a writable copy of the modulus or a padded result buffer. The working state required is only two bits larger than the result buffer, and these additional bits may be held in local variables instead. Rewrite bigint_reduce() to handle only this use case, and remove the no longer necessary uses of double-sized big integers. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Expose shifted out bit from big integer shiftsMichael Brown10 days1-6/+8
| | | | | | | Expose the bit shifted out as a result of shifting a big integer left or right. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [malloc] Ensure free memory blocks remain alignedMichael Brown2025-02-031-1/+0
| | | | | | | | | | | | | | | When allocating memory with a non-zero alignment offset, the free memory block structure following the allocation may end up improperly aligned. Ensure that free memory blocks always remain aligned to the size of the free memory block structure. Ensure that the initial heap is also correctly aligned, thereby allowing the logic for leaking undersized free memory blocks to be omitted. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Add definitions and tests for the NIST P-384 elliptic curveMichael Brown2025-01-303-0/+25
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Add definitions and tests for the NIST P-256 elliptic curveMichael Brown2025-01-283-0/+26
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Add support for Weierstrass elliptic curve point multiplicationMichael Brown2025-01-282-0/+167
| | | | | | | | | | | | | | | | | | | | | | | | The NIST elliptic curves are Weierstrass curves and have the form y^2 = x^3 + ax + b with each curve defined by its field prime, the constants "a" and "b", and a generator base point. Implement a constant-time algorithm for point addition, based upon Algorithm 1 from "Complete addition formulas for prime order elliptic curves" (Joost Renes, Craig Costello, and Lejla Batina), and use this as a Montgomery ladder commutative operation to perform constant-time point multiplication. The code for point addition is implemented using a custom bytecode interpreter with 16-bit instructions, since this results in substantially smaller code than compiling the somewhat lengthy sequence of arithmetic operations directly. Values are calculated modulo small multiples of the field prime in order to allow for the use of relaxed Montgomery reduction. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Add a generic implementation of a Montgomery ladderMichael Brown2025-01-281-0/+40
| | | | | | | | | | | | | | | | The Montgomery ladder may be used to perform any operation that is isomorphic to exponentiation, i.e. to compute the result r = g^e = g * g * g * g * .... * g for an arbitrary commutative operation "*", base or generator "g", and exponent "e". Implement a generic Montgomery ladder for use by both modular exponentiation and elliptic curve point multiplication (both of which are isomorphic to exponentiation). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [tls] Allow for NIST elliptic curve point formatsMichael Brown2025-01-212-1/+10
| | | | | | | | | | | | | | | | | | | | | The elliptic curve point representation for the x25519 curve includes only the X value, since the curve is designed such that the Montgomery ladder does not need to ever know or calculate a Y value. There is no curve point format byte: the public key data is simply the X value. The pre-master secret is also simply the X value of the shared secret curve point. The point representation for the NIST curves includes both X and Y values, and a single curve point format byte that must indicate that the format is uncompressed. The pre-master secret for the NIST curves does not include both X and Y values: only the X value is used. Extend the definition of an elliptic curve to allow the point size to be specified separately from the key size, and extend the definition of a TLS named curve to include an optional curve point format byte and a pre-master secret length. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Generalise elliptic curve key exchange to ecdhe_key()Michael Brown2025-01-211-0/+17
| | | | | | | | Split out the portion of tls_send_client_key_exchange_ecdhe() that actually performs the elliptic curve key exchange into a separate function ecdhe_key(). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Add bigint_ntoa() for transcribing big integersMichael Brown2025-01-201-0/+13
| | | | | | | | | | | | | | | | | In debug messages, big integers are currently printed as hex dumps. This is quite verbose and cumbersome to check against external sources. Add bigint_ntoa() to transcribe big integers into a static buffer (following the model of inet_ntoa(), eth_ntoa(), uuid_ntoa(), etc). Abbreviate big integers that will not fit within the static buffer, showing both the most significant and least significant digits in the transcription. This is generally the most useful form when visually comparing against external sources (such as test vectors, or results produced by high-level languages). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Extract bigint_reduce_supremum() from bigint_mod_exp()Michael Brown2025-01-101-3/+18
| | | | | | | | | | | | Calculating the Montgomery constant (R^2 mod N) is done in our implementation by zeroing the double-width representation of N, subtracting N once to give (R^2 - N) in order to obtain a positive value, then reducing this value modulo N. Extract this logic from bigint_mod_exp() to a separate function bigint_reduce_supremum(), to allow for reuse by other code. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Allow for relaxed Montgomery reductionMichael Brown2024-12-181-10/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Classic Montgomery reduction involves a single conditional subtraction to ensure that the result is strictly less than the modulus. When performing chains of Montgomery multiplications (potentially interspersed with additions and subtractions), it can be useful to work with values that are stored modulo some small multiple of the modulus, thereby allowing some reductions to be elided. Each addition and subtraction stage will increase this running multiple, and the following multiplication stages can be used to reduce the running multiple since the reduction carried out for multiplication products is generally strong enough to absorb some additional bits in the inputs. This approach is already used in the x25519 code, where multiplication takes two 258-bit inputs and produces a 257-bit output. Split out the conditional subtraction from bigint_montgomery() and provide a separate bigint_montgomery_relaxed() for callers who do not require immediate reduction to within the range of the modulus. Modular exponentiation could potentially make use of relaxed Montgomery multiplication, but this would require R>4N, i.e. that the two most significant bits of the modulus be zero. For both RSA and DHE, this would necessitate extending the modulus size by one element, which would negate any speed increase from omitting the conditional subtractions. We therefore retain the use of classic Montgomery reduction for modular exponentiation, apart from the final conversion out of Montgomery form. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Add EFI_TCG2_PROTOCOL header and GUID definitionMichael Brown2024-12-172-0/+338
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Update to current EDK2 headersMichael Brown2024-12-1719-84/+535
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Calculate inverse of modulus on demand in bigint_montgomery()Michael Brown2024-12-161-5/+3
| | | | | | | | | | | | | Reduce the number of parameters passed to bigint_montgomery() by calculating the inverse of the modulus modulo the element size on demand. Cache the result, since Montgomery reduction will be used repeatedly with the same modulus value. In all currently supported algorithms, the modulus is a public value (or a fixed value defined by specification) and so this non-constant timing does not leak any private information. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Remove obsolete bigint_mod_multiply()Michael Brown2024-11-281-36/+0
| | | | | | | | | | There is no further need for a standalone modular multiplication primitive, since the only consumer is modular exponentiation (which now uses Montgomery multiplication instead). Remove the now obsolete bigint_mod_multiply(). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Use Montgomery reduction for modular exponentiationMichael Brown2024-11-281-8/+2
| | | | | | | | | | | | | | | | | Speed up modular exponentiation by using Montgomery reduction rather than direct modular reduction. Montgomery reduction in base 2^n requires the modulus to be coprime to 2^n, which would limit us to requiring that the modulus is an odd number. Extend the implementation to include support for exponentiation with even moduli via Garner's algorithm as described in "Montgomery reduction with even modulus" (Koç, 1994). Since almost all use cases for modular exponentation require a large prime (and hence odd) modulus, the support for even moduli could potentially be removed in future. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Add bigint_montgomery() to perform Montgomery reductionMichael Brown2024-11-271-0/+21
| | | | | | | | | | Montgomery reduction is substantially faster than direct reduction, and is better suited for modular exponentiation operations. Add bigint_montgomery() to perform the Montgomery reduction operation (often referred to as "REDC"), along with some test vectors. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Use inverse size as effective size for bigint_mod_invert()Michael Brown2024-11-271-1/+1
| | | | | | | | | | | | Montgomery reduction requires only the least significant element of an inverse modulo 2^k, which in turn depends upon only the least significant element of the invertend. Use the inverse size (rather than the invertend size) as the effective size for bigint_mod_invert(). This eliminates around 97% of the loop iterations for a typical 2048-bit RSA modulus. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Eliminate temporary working space for bigint_mod_invert()Michael Brown2024-11-271-19/+5
| | | | | | | | | | With a slight modification to the algorithm to ignore bits of the residue that can never contribute to the result, it is possible to reuse the as-yet uncalculated portions of the inverse to hold the residue. This removes the requirement for additional temporary working space. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Eliminate temporary working space for bigint_reduce()Michael Brown2024-11-261-27/+7
| | | | | | | | | | | | | | | | Direct modular reduction is expected to be used in situations where there is no requirement to retain the original (unreduced) value. Modify the API for bigint_reduce() to reduce the value in place, (removing the separate result buffer), impose a constraint that the modulus and value have the same size, and require the modulus to be passed in writable memory (to allow for scaling in place). This removes the requirement for additional temporary working space. Reverse the order of arguments so that the constant input is first, to match the usage pattern for bigint_add() et al. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Expose carry flag from big integer addition and subtractionMichael Brown2024-11-261-8/+10
| | | | | | | | Expose the effective carry (or borrow) out flag from big integer addition and subtraction, and use this to elide an explicit bit test when performing x25519 reduction. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Add bigint_msb_is_set() to clarify codeMichael Brown2024-11-201-0/+27
| | | | | | | | Add a dedicated bigint_msb_is_set() to reduce the amount of open coding required in the common case of testing the sign of a two's complement big integer. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pci] Provide a null PCI API for platforms with no PCI busMichael Brown2024-10-282-0/+155
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [fdt] Add ability to parse unsigned integer propertiesMichael Brown2024-10-281-0/+1
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [uaccess] Rename UACCESS_EFI to UACCESS_FLATMichael Brown2024-10-252-104/+75
| | | | | | | | | Running with flat physical addressing is a fairly common early boot environment. Rename UACCESS_EFI to UACCESS_FLAT so that this code may be reused in non-UEFI boot environments that also use flat physical addressing. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [smbios] Provide a null SMBIOS API for platforms with no concept of SMBIOSMichael Brown2024-10-253-0/+20
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Add bigint_mod_invert() to calculate inverse modulo a power of twoMichael Brown2024-10-211-0/+28
| | | | | | | | | | | | | | | | | Montgomery multiplication requires calculating the inverse of the modulus modulo a larger power of two. Add bigint_mod_invert() to calculate the inverse of any (odd) big integer modulo an arbitrary power of two, using a lightly modified version of the algorithm presented in "A New Algorithm for Inversion mod p^k (Koç, 2017)". The power of two is taken to be 2^k, where k is the number of bits available in the big integer representation of the invertend. The inverse modulo any smaller power of two may be obtained simply by masking off the relevant bits in the inverse. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [usb] Expose USB device descriptor and strings via settingsMichael Brown2024-10-181-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Allow scripts to read basic information from USB device descriptors via the settings mechanism. For example: echo USB vendor ID: ${usb/${busloc}.8.2} echo USB device ID: ${usb/${busloc}.10.2} echo USB manufacturer name: ${usb/${busloc}.14.0} The general syntax is usb/<bus:dev>.<offset>.<length> where bus:dev is the USB bus:device address (as obtained via the "usbscan" command, or from e.g. ${net0/busloc} for a USB network device), and <offset> and <length> select the required portion of the USB device descriptor. Following the usage of SMBIOS settings tags, a <length> of zero may be used to indicate that the byte at <offset> contains a USB string descriptor index, and an <offset> of zero may be used to indicate that the <length> contains a literal USB string descriptor index. Since the byte at offset zero can never contain a string index, and a literal string index can never be zero, the combination of both <length> and <offset> being zero may be used to indicate that the entire device descriptor is to be read as a raw hex dump. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [usb] Add "usbscan" command for iterating over USB devicesMichael Brown2024-10-172-0/+26
| | | | | | | | Implement a "usbscan" command as a direct analogy of the existing "pciscan" command, allowing scripts to iterate over all detected USB devices. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Separate out bigint_reduce() from bigint_mod_multiply()Michael Brown2024-10-151-0/+34
| | | | | | | | | | | Faster modular multiplication algorithms such as Montgomery multiplication will still require the ability to perform a single direct modular reduction. Neaten up the implementation of direct reduction and split it out into a separate bigint_reduce() function, complete with its own unit tests. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Use architecture-independent bigint_is_set()Michael Brown2024-10-101-0/+19
| | | | | | | | | | | Every architecture uses the same implementation for bigint_is_set(), and there is no reason to suspect that a future CPU architecture will provide a more efficient way to implement this operation. Simplify the code by providing a single architecture-independent implementation of bigint_is_set(). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Rename bigint_rol()/bigint_ror() to bigint_shl()/bigint_shr()Michael Brown2024-10-071-8/+8
| | | | | | | | | | | The big integer shift operations are misleadingly described as rotations since the original x86 implementations are essentially trivial loops around the relevant rotate-through-carry instruction. The overall operation performed is a shift rather than a rotation. Update the function names and descriptions to reflect this. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Eliminate temporary carry space for big integer multiplicationMichael Brown2024-09-271-10/+4
| | | | | | | | | | | | An n-bit multiplication product may be added to up to two n-bit integers without exceeding the range of a (2n)-bit integer: (2^n - 1)*(2^n - 1) + (2^n - 1) + (2^n - 1) = 2^(2n) - 1 Exploit this to perform big integer multiplication in constant time without requiring the caller to provide temporary carry space. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [profile] Standardise return type of profile_timestamp()Michael Brown2024-09-241-0/+2
| | | | | | | | | | | | | | | | All consumers of profile_timestamp() currently treat the value as an unsigned long. Only the elapsed number of ticks is ever relevant: the absolute value of the timestamp is not used. Profiling is used to measure short durations that are generally fewer than a million CPU cycles, for which an unsigned long is easily large enough. Standardise the return type of profile_timestamp() as unsigned long across all CPU architectures. This allows 32-bit architectures such as i386 and riscv32 to omit all logic associated with retrieving the upper 32 bits of the 64-bit hardware counter, which simplifies the code and allows riscv32 and riscv64 to share the same implementation. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Use constant-time big integer multiplicationMichael Brown2024-09-231-4/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Big integer multiplication currently performs immediate carry propagation from each step of the long multiplication, relying on the fact that the overall result has a known maximum value to minimise the number of carries performed without ever needing to explicitly check against the result buffer size. This is not a constant-time algorithm, since the number of carries performed will be a function of the input values. We could make it constant-time by always continuing to propagate the carry until reaching the end of the result buffer, but this would introduce a large number of redundant zero carries. Require callers of bigint_multiply() to provide a temporary carry storage buffer, of the same size as the result buffer. This allows the carry-out from the accumulation of each double-element product to be accumulated in the temporary carry space, and then added in via a single call to bigint_add() after the multiplication is complete. Since the structure of big integer multiplication is identical across all current CPU architectures, provide a single shared implementation of bigint_multiply(). The architecture-specific operation then becomes the multiplication of two big integer elements and the accumulation of the double-element product. Note that any intermediate carry arising from accumulating the lower half of the double-element product may be added to the upper half of the double-element product without risk of overflow, since the result of multiplying two n-bit integers can never have all n bits set in its upper half. This simplifies the carry calculations for architectures such as RISC-V and LoongArch64 that do not have a carry flag. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [riscv] Add support for the RISC-V CPU architectureMichael Brown2024-09-152-0/+179
| | | | | | | | | | | | | | | | | | | | | | | | Add support for building iPXE as a 64-bit or 32-bit RISC-V binary, for either UEFI or Linux userspace platforms. For example: # RISC-V 64-bit UEFI make CROSS=riscv64-linux-gnu- bin-riscv64-efi/ipxe.efi # RISC-V 32-bit UEFI make CROSS=riscv64-linux-gnu- bin-riscv32-efi/ipxe.efi # RISC-V 64-bit Linux make CROSS=riscv64-linux-gnu- bin-riscv64-linux/tests.linux qemu-riscv64 -L /usr/riscv64-linux-gnu/sys-root \ ./bin-riscv64-linux/tests.linux # RISC-V 32-bit Linux make CROSS=riscv64-linux-gnu- SYSROOT=/usr/riscv32-linux-gnu/sys-root \ bin-riscv32-linux/tests.linux qemu-riscv32 -L /usr/riscv32-linux-gnu/sys-root \ ./bin-riscv32-linux/tests.linux Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Centralise definition of efi_cpu_nap()Michael Brown2024-09-132-0/+25
| | | | | | | | | Define a cpu_halt() function which is architecture-specific but platform-independent, and merge the multiple architecture-specific implementations of the EFI cpu_nap() function into a single central efi_cpu_nap() that uses cpu_halt() if applicable. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [libc] Centralise architecture-independent portions of setjmp.hMichael Brown2024-09-121-0/+14
| | | | | | | | | | | The definitions of the setjmp() and longjmp() functions are common to all architectures, with only the definition of the jump buffer structure being architecture-specific. Move the architecture-specific portions to bits/setjmp.h and provide a common setjmp.h for the function definitions. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [gdb] Allow CPU architectures to omit support for GDBMichael Brown2024-09-052-1/+46
| | | | | | | | Move the <gdbmach.h> file to <bits/gdbmach.h>, and provide a common dummy implementation for all architectures that have not yet implemented support for GDB. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Centralise dummy architecture-specific headersMichael Brown2024-09-0315-0/+243
| | | | | | | | Simplify the process of adding a new CPU architecture by providing common implementations of typically empty architecture-specific header files. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [aqc1xx] Add support for Marvell AQtion Ethernet controlleraqc1xxAnimesh Bhatt2024-09-021-0/+3
| | | | | | | | | This patch adds support for the AQtion Ethernet controller, enabling iPXE to recognize and utilize the specific models (AQC114, AQC113, and AQC107). Tested-by: Animesh Bhatt <animeshb@marvell.com> Signed-off-by: Animesh Bhatt <animeshb@marvell.com>
* [image] Add the "imgdecrypt" commandMichael Brown2024-08-291-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add the "imgdecrypt" command that can be used to decrypt a detached encrypted data image using a cipher key obtained from a separate CMS envelope image. For example: # Create non-detached encrypted CMS messages # openssl cms -encrypt -binary -aes-256-gcm -recip client.crt \ -in vmlinuz -outform DER -out vmlinuz.cms openssl cms -encrypt -binary -aes-256-gcm -recip client.crt \ -in initrd.img -outform DER -out initrd.img.cms # Detach data from envelopes (using iPXE's contrib/crypto/cmsdetach) # cmsdetach vmlinuz.cms -d vmlinuz.dat -e vmlinuz.env cmsdetach initrd.img.cms -d initrd.img.dat -e initrd.img.env and then within iPXE: #!ipxe imgfetch http://192.168.0.1/vmlinuz.dat imgfetch http://192.168.0.1/initrd.img.dat imgdecrypt vmlinuz.dat http://192.168.0.1/vmlinuz.env imgdecrypt initrd.img.dat http://192.168.0.1/initrd.img.env boot vmlinuz Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Support decryption of images via CMS envelopesMichael Brown2024-08-292-0/+35
| | | | | | | | Add support for decrypting images containing detached encrypted data using a cipher key obtained from a separate CMS envelope image (in DER or PEM format). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [image] Split image_strip_suffix() out from image_extract()Michael Brown2024-08-291-0/+1
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Allow for extraction of ASN.1 algorithm parametersMichael Brown2024-08-281-2/+17
| | | | | | | | | | | Some ASN.1 OID-identified algorithms require additional parameters, such as an initialisation vector for a block cipher. The structure of the parameters is defined by the individual algorithm. Extend asn1_algorithm() to allow these additional parameters to be returned via a separate ASN.1 cursor. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Hold CMS message as a single ASN.1 objectMichael Brown2024-08-231-3/+3
| | | | | | | | | | Reduce the number of dynamic allocations required to parse a CMS message by retaining the ASN.1 cursor returned from image_asn1() for the lifetime of the CMS message. This allows embedded ASN.1 cursors to be used for parsed objects within the message, such as embedded signatures. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Remove the concept of a public-key algorithm reusable contextMichael Brown2024-08-213-85/+40
| | | | | | | | | | | | | | | | | | | | | | | Instances of cipher and digest algorithms tend to get called repeatedly to process substantial amounts of data. This is not true for public-key algorithms, which tend to get called only once or twice for a given key. Simplify the public-key algorithm API so that there is no reusable algorithm context. In particular, this allows callers to omit the error handling currently required to handle memory allocation (or key parsing) errors from pubkey_init(), and to omit the cleanup calls to pubkey_final(). This change does remove the ability for a caller to distinguish between a verification failure due to a memory allocation failure and a verification failure due to a bad signature. This difference is not material in practice: in both cases, for whatever reason, the caller was unable to verify the signature and so cannot proceed further, and the cause of the error will be visible to the user via the return status code. Signed-off-by: Michael Brown <mcb30@ipxe.org>
generated by cgit (git 2.34.1) at 2025-02-23 13:15:10 +0000