aboutsummaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
...
* [crypto] Use architecture-independent bigint_is_set()Michael Brown2024-10-106-95/+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-078-60/+60
| | | | | | | | | | | 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-279-197/+111
| | | | | | | | | | | | 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>
* [arm] Support building as a Linux userspace binary for AArch32Michael Brown2024-09-241-0/+25
| | | | | | | | | | | | | Add support for building as a Linux userspace binary for AArch32. This allows the self-test suite to be more easily run for the 32-bit ARM code. For example: make CROSS=arm-linux-gnu- bin-arm32-linux/tests.linux qemu-arm -L /usr/arm-linux-gnu/sys-root/ \ ./bin-arm32-linux/tests.linux Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [arm] Check PMCCNTR availability before use for profilingMichael Brown2024-09-242-3/+99
| | | | | | | | | | | | Reading from PMCCNTR causes an undefined instruction exception when running in PL0 (e.g. as a Linux userspace binary), unless the PMUSERENR.EN bit is set. Restructure profile_timestamp() for 32-bit ARM to perform an availability check on the first invocation, with subsequent invocations returning zero if PMCCNTR could not be enabled. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [profile] Standardise return type of profile_timestamp()Michael Brown2024-09-248-45/+11
| | | | | | | | | | | | | | | | 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-2314-612/+355
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* [gve] Allocate all possible event countersMichael Brown2024-09-172-64/+76
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The admin queue API requires us to tell the device how many event counters we have provided via the "configure device resources" admin queue command. There is, of course, absolutely no documentation indicating how many event counters actually need to be provided. We require only two event counters: one for the transmit queue, one for the receive queue. (The receive queue doesn't seem to actually make any use of its event counter, but the "create receive queue" admin queue command will fail if it doesn't have an available event counter to choose.) In the absence of any documentation, we currently make the assumption that allocating and configuring 16 counters (i.e. one whole cacheline) will be sufficient to allow for the use of two counters. This assumption turns out to be incorrect. On larger instance types (observed with a c3d-standard-16 instance in europe-west4-a), we find that creating the transmit or receive queues will each fail with a probability of around 50% with the "failed precondition" error code. Experimentation suggests that even though the device has accepted our "configure device resources" command indicating that we are providing only 16 event counters, it will attempt to choose any of its potential 32 event counters (and will then fail since the event counter that it unilaterally chose is outside of the agreed range). Work around this firmware bug by always allocating the maximum number of event counters supported by the device. (This requires deferring the allocation of the event counters until after issuing the "describe device" command.) Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Remove redundant EFI_BOOT_FILE definitionsMichael Brown2024-09-167-28/+0
| | | | | | | | | | | | As of commit 79c0173 ("[build] Create util/genfsimg for building filesystem-based images"), the EFI boot file name for each CPU architecture is defined within the genfsimg script itself, rather than being passed in as a Makefile parameter. Remove the now-redundant Makefile definitions for EFI_BOOT_FILE. Reported-by: Christian I. Nilsson <nikize@gmail.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [riscv] Add support for the RISC-V CPU architectureMichael Brown2024-09-1542-0/+2405
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* [linux] Allow a sysroot to be specified via SYSROOT=...Michael Brown2024-09-151-0/+3
| | | | | | | | | | | | | | | The cross-compiler will typically use the appropriate sysroot directory automatically. This may not work for toolchains where a single cross-compiler is used to produce output for multiple CPU variants (e.g. 32-bit and 64-bit RISC-V). Add a SYSROOT=... parameter that may be used to specify the relevant sysroot directory, e.g. make CROSS=riscv64-linux-gnu- SYSROOT=/usr/riscv32-linux-gnu/sys-root \ bin-riscv32-linux/tests.linux Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Use standard va_args macros instead of VA_START() etcMichael Brown2024-09-151-12/+12
| | | | | | | | | | The EDK2 header macros VA_START(), VA_ARG() etc produce build errors on some CPU architectures (notably on 32-bit RISC-V, which is not yet supported by EDK2). Fix by using the standard variable argument list macros. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [test] Add tests for 64-bit logical and arithmetic shiftsMichael Brown2024-09-151-0/+117
| | | | | | | For some 32-bit CPUs, we need to provide implementations of 64-bit shifts as libgcc helper functions. Add test cases to cover these. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Centralise definition of efi_cpu_nap()Michael Brown2024-09-1312-179/+53
| | | | | | | | | 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-126-54/+36
| | | | | | | | | | | 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>
* [cloud] Add ability to delete old AMI imagesMichael Brown2024-09-091-10/+30
| | | | | | | Add the "--retain <N>" option to limit the number of retained old AMI images (within the same family, architecture, and public visibility). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [cloud] Add family and architecture tags to AWS snapshots and imagesMichael Brown2024-09-061-5/+21
| | | | | | | | Allow for easier identification of images and snapshots created by the aws-import script by adding tags for image family (e.g. "iPXE") and architecture (e.g. "x86_64") to both. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [ena] Change reported operating system type to "iPXE"enaMichael Brown2024-09-052-8/+14
| | | | | | | | | | | | | | | | | | | | | | | | | As described in commit 3b81a4e ("[ena] Provide a host information page"), we currently report an operating system type of "Linux" in order to work around broken versions of the ENA firmware that will fail to create a completion queue if we report the correct operating system type. As of September 2024, the ENA team at AWS assures us that the entire AWS fleet has been upgraded to fix this bug, and that we are now safe to report the correct operating system type value in the "type" field of struct ena_host_info. The ENA team has also clarified that at least some deployed versions of the ENA firmware still have the defect that requires us to report an operating system version number of 2 (regardless of operating system type), and so we continue to report ENA_HOST_INFO_VERSION_WTF in the "version" field of struct ena_host_info. Add an explicit warning on the previous known failure path, in case some deployed versions of the ENA firmware turn out to not have been upgraded as expected. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [gdb] Allow CPU architectures to omit support for GDBMichael Brown2024-09-058-99/+7
| | | | | | | | 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-0345-336/+238
| | | | | | | | 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-028-0/+1618
| | | | | | | | | 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>
* [etherfabric] Fix use of uninitialised variable in falcon_xaui_link_ok()Michael Brown2024-09-021-6/+9
| | | | | | | | | | | | | | The link status check in falcon_xaui_link_ok() reads from the FCN_XX_CORE_STAT_REG_MAC register only on production hardware (where the FPGA version reads as zero), but modifies the value and writes back to this register unconditionally. This triggers an uninitialised variable warning on newer versions of gcc. Fix by assuming that the register exists only on production hardware, and so moving the "modify-write" portion of the "read-modify-write" operation to also be covered by the same conditional check. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [test] Add CMS decryption self-testsMichael Brown2024-08-291-2/+353
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Allow cms_decrypt() to be called on unregistered imagesMichael Brown2024-08-291-9/+15
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [image] Add the "imgdecrypt" commandMichael Brown2024-08-295-0/+220
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-293-17/+529
| | | | | | | | 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-293-5/+22
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Add cmsdetach script for detaching encrypted data from CMS messagesMichael Brown2024-08-281-0/+80
| | | | | | | | | | | | | | | | The openssl toolchain does not currently seem to support creating CMS envelopedData or authEnvelopedData messages with detached encrypted data. Add a standalone tool "cmsdetach" that can be used to detach the encrypted data from a CMS message. For example: openssl cms -encrypt -binary -aes-256-gcm -recip client.crt \ -in bootfile -outform DER -out bootfile.cms cmsdetach bootfile.cms --data bootfile.dat --envelope bootfile.env Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [test] Update CMS self-test terminologyMichael Brown2024-08-281-59/+58
| | | | | | | | Generalise CMS self-test data structure and macro names to refer to "messages" rather than "signatures", in preparation for adding image decryption tests. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Allow for extraction of ASN.1 algorithm parametersMichael Brown2024-08-284-11/+92
| | | | | | | | | | | 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-232-29/+15
| | | | | | | | | | 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-2111-398/+304
| | | | | | | | | | | | | | | | | | | | | | | 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>
* [tls] Group client and server state in TLS connection structureMichael Brown2024-08-212-128/+147
| | | | | | | | | | | | The TLS connection structure has grown to become unmanageably large as new features and support for new TLS protocol versions have been added over time. Split out the portions of struct tls_connection that are specific to client and server operations into separate structures, and simplify some structure field names. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [tls] Group transmit and receive state in TLS connection structureMichael Brown2024-08-212-108/+119
| | | | | | | | | | | | The TLS connection structure has grown to become unmanageably large as new features and support for new TLS protocol versions have been added over time. Split out the portions of struct tls_connection that are specific to transmit and receive operations into separate structures, and simplify some structure field names. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [gve] Add missing error codes in EUNIQ() list of potential errorsMichael Brown2024-08-201-4/+5
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [contrib] Remove obsolete rom-o-matic codeMichael Brown2024-08-2042-1955/+0
| | | | | | | | | | | | | | | The rom-o-matic code does not form part of the iPXE codebase, has not been maintained for over a decade, and does not appear to still be in use anywhere in the world. It does, however, result in a large number of false positive security vulnerability reports from some low quality automated code analysis tools such as Fortify SCA. Remove this unused and obsolete code to reduce the burden of responding to these false positives. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [test] Generalise public-key algorithm tests and use okx()Michael Brown2024-08-183-309/+336
| | | | | | | | Generalise the existing support for performing RSA public-key encryption, decryption, signature, and verification tests, and update the code to use okx() for neater reporting of test results. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Pass asymmetric keys as ASN.1 cursorsMichael Brown2024-08-1810-112/+74
| | | | | | | | | | | Asymmetric keys are invariably encountered within ASN.1 structures such as X.509 certificates, and the various large integers within an RSA key are themselves encoded using ASN.1. Simplify all code handling asymmetric keys by passing keys as a single ASN.1 cursor, rather than separate data and length pointers. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Allow discovery of PCI bus:dev.fn address rangesMichael Brown2024-08-152-78/+176
| | | | | | | | | | | Generalise the logic for identifying the matching PCI root bridge I/O protocol to allow for identifying the closest matching PCI bus:dev.fn address range, and use this to provide PCI address range discovery (while continuing to inhibit automatic PCI bus probing). This allows the "pciscan" command to work as expected under UEFI. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pci] Separate permission to probe buses from bus:dev.fn range discoveryMichael Brown2024-08-1514-0/+77
| | | | | | | | | | | | | | | | | The UEFI device model requires us to not probe the PCI bus directly, but instead to wait to be offered the opportunity to drive devices via our driver service binding handle. We currently inhibit PCI bus probing by having pci_discover() return an empty range when using the EFI PCI I/O API. This has the unwanted side effect that scanning the bus manually using the "pciscan" command will also fail to discover any devices. Separate out the concept of being allowed to probe PCI buses from the mechanism for discovering PCI bus:dev.fn address ranges, so that this limitation may be removed. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Fix debug name for empty certificate chain validatorsMichael Brown2024-08-141-2/+4
| | | | | | | | | | | | | | | | | An attempt to use a validator for an empty certificate chain will correctly fail the overall validation with the "empty certificate chain" error propagated from x509_auto_append(). In a debug build, the call to validator_name() will attempt to call x509_name() on a non-existent certificate, resulting in garbage in the debug message. Fix by checking for the special case of an empty certificate chain. This issue does not affect non-debug builds, since validator_name() is (as per its description) called only for debug messages. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Generalise cms_signature to cms_messageMichael Brown2024-08-145-284/+364
| | | | | | | | | | | | | | | | | There is some exploitable similarity between the data structures used for representing CMS signatures and CMS encryption keys. In both cases, the CMS message fundamentally encodes a list of participants (either message signers or message recipients), where each participant has an associated certificate and an opaque octet string representing the signature or encrypted cipher key. The ASN.1 structures are not identical, but are sufficiently similar to be worth exploiting: for example, the SignerIdentifier and RecipientIdentifier data structures are defined identically. Rename data structures and functions, and add the concept of a CMS message type. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Add OID-identified algorithms for AES ciphersMichael Brown2024-08-145-0/+196
| | | | | | | Extend the definition of an ASN.1 OID-identified algorithm to include a potential cipher suite, and add identifiers for AES-CBC and AES-GCM. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Pass image as parameter to CMS functionsMichael Brown2024-08-134-65/+101
| | | | | | | | | | | | | The cms_signature() and cms_verify() functions currently accept raw data pointers. This will not be possible for cms_decrypt(), which will need the ability to extract fragments of ASN.1 data from a potentially large image. Change cms_signature() and cms_verify() to accept an image as an input parameter, and move the responsibility for setting the image trust flag within cms_verify() since that now becomes a more natural fit. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Allow passing a NULL certificate store to x509_find() et alMichael Brown2024-08-134-40/+55
| | | | | | | | | | Allow passing a NULL value for the certificate list to all functions used for identifying an X.509 certificate from an existing set of certificates, and rename function parameters to indicate that this certificate list represents an unordered certificate store (rather than an ordered certificate chain). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Centralise mechanisms for identifying X.509 certificatesMichael Brown2024-08-126-87/+133
| | | | | | | | | Centralise all current mechanisms for identifying an X.509 certificate (by raw content, by subject, by issuer and serial number, and by matching public key), and remove the certstore-specific and CMS-specific variants of these functions. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Extend asn1_enter() to handle partial object cursorsMichael Brown2024-08-073-22/+43
| | | | | | | | | | | | | | | | | | | | | | | Handling large ASN.1 objects such as encrypted CMS files will require the ability to use the asn1_enter() and asn1_skip() family of functions on partial object cursors, where a defined additional length is known to exist after the end of the data buffer pointed to by the ASN.1 object cursor. We already have support for partial object cursors in the underlying asn1_start() operation used by both asn1_enter() and asn1_skip(), and this is used by the DER image probe routine to check that the potential DER file comprises a single ASN.1 SEQUENCE object. Add asn1_enter_partial() to formalise the process of entering an ASN.1 partial object, and refactor the DER image probe routine to use this instead of open-coding calls to the underlying asn1_start() operation. There is no need for an equivalent asn1_skip_partial() function, since only objects that are wholly contained within the partial cursor may be successfully skipped. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Clarify ASN.1 cursor invalidation behaviourMichael Brown2024-08-071-8/+21
| | | | | | | | | | | | | | | Calling asn1_skip_if_exists() on a malformed ASN.1 object may currently leave the cursor in a partially-updated state, where the tag byte and one of the length bytes have been stripped. The cursor is left with a valid data pointer and length and so no out-of-bounds access can arise, but the cursor no longer points to the start of an ASN.1 object. Ensure that each ASN.1 cursor manipulation code path leads to the cursor being either fully updated, left unmodified, or invalidated, and update the function descriptions to reflect this. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Do not return an error when skipping the final ASN.1 objectMichael Brown2024-08-071-5/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Successfully reaching the end of a well-formed ASN.1 object list is arguably not an error, but the current code (dating back to the original ASN.1 commit in 2007) will explicitly check for and report this as an error condition. Remove the explicit check for reaching the end of a well-formed ASN.1 object list, and instead return success along with a zero-length (and hence implicitly invalidated) cursor. Almost every existing caller of asn1_skip() or asn1_skip_if_exists() currently ignores the return value anyway. Skipped objects are (by definition) not of interest to the caller, and the invalidation behaviour of asn1_skip() ensures that any errors will be safely caught on a subsequent attempt to actually use the ASN.1 object content. Since these existing callers ignore the return value, they cannot be affected by this change. There is one existing caller of asn1_skip_if_exists() that does check the return value: in asn1_skip() itself, an error returned from asn1_skip_if_exists() will cause the cursor to be invalidated. In the case of an error indicating only that the cursor length is already zero, invalidation is a no-op, and so this change affects only the return value propagated from asn1_skip(). This leaves only a single call site within ocsp_request() where the return value from asn1_skip() is currently checked. The return status here is moot since there is no way for the code in question to fail (absent a bug in the ASN.1 construction or parsing code). There are therefore no callers of asn1_skip() or asn1_skip_if_exists() that rely on an error being returned for successfully reaching the end of a well-formed ASN.1 object list. Simplify the code by redefining this as a successful outcome. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [cpuid] Allow hypervisor CPUID leaves to be accessed as settingsMichael Brown2024-08-011-4/+14
| | | | | | | | | | | | Redefine bit 30 of an SMBIOS numerical setting to be part of the function number, in order to allow access to hypervisor CPUID leaves. This technically breaks backwards compatibility with scripts attempting to read more than 64 consecutive functions. Since there is no meaningful block of 64 consecutive related functions, it is vanishingly unlikely that this capability has ever been used. Signed-off-by: Michael Brown <mcb30@ipxe.org>
generated by cgit (git 2.34.1) at 2025-02-23 03:45:37 +0000