aboutsummaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* [menu] Allow a post-activity timeout to be definedHEADmastercoverity_scanMichael Brown3 days3-9/+20
| | | | | | | | | 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 Brown4 days2-23/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* [efi] Increase download timeout for autoexec.ipxeMichael Brown5 days1-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | In almost all cases, the download timeout for autoexec.ipxe is irrelevant: the operation will either succeed or fail relatively quickly (e.g. due to a nonexistent file). The overall download timeout exists only to ensure that an unattended or headless system will not wait indefinitely in the case of a degenerate network response (e.g. an HTTP server that returns an endless trickle of data using chunked transfer encoding without ever reaching the end of the file). The current download timeout is too short if PeerDist content encoding is enabled, since the overall download will abort before the first peer discovery attempt has completed, and without allowing sufficient time for an origin server range request. The single timeout value is currently used for both the download timeout and the sync timeout. The latter timeout exists only to allow network communication to be gracefully quiesced before removing the temporary MNP network device, and may safely be shortened without affecting functionality. Fix by increasing the download timeout from two seconds to 30 seconds, and defining a separate one-second timeout for the sync operation. 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 Brown8 days4-233/+221
| | | | | | | | | | | | | | | | | | | | | | 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 Brown9 days7-85/+146
| | | | | | | Expose the bit shifted out as a result of shifting a big integer left or right. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [bnxt] Allocate TX rings with firmware inputJoseph Wong2025-02-072-2/+1
| | | | | | | Use queue_id value retrieved from firmware unconditionally when allocating TX rings. Signed-off by: Joseph Wong <joseph.wong@broadcom.com>
* [malloc] Ensure free memory blocks remain alignedMichael Brown2025-02-032-40/+58
| | | | | | | | | | | | | | | 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>
* [malloc] Clean up debug messagesMichael Brown2025-02-031-29/+30
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Add definitions and tests for the NIST P-384 elliptic curveMichael Brown2025-01-309-0/+379
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Add definitions and tests for the NIST P-256 elliptic curveMichael Brown2025-01-289-0/+325
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Add support for Weierstrass elliptic curve point multiplicationMichael Brown2025-01-283-0/+1044
| | | | | | | | | | | | | | | | | | | | | | | | 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-282-34/+194
| | | | | | | | | | | | | | | | 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>
* [test] Add generic tests for elliptic curve point multiplicationMichael Brown2025-01-222-0/+153
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [tls] Allow for NIST elliptic curve point formatsMichael Brown2025-01-215-11/+40
| | | | | | | | | | | | | | | | | | | | | 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-213-9/+87
| | | | | | | | 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-202-0/+60
| | | | | | | | | | | | | | | | | 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-102-7/+44
| | | | | | | | | | | | 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-183-33/+184
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-174-0/+345
| | | | 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-163-36/+23
| | | | | | | | | | | | | 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>
* [gve] Run startup process only while device is openMichael Brown2024-12-031-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | The startup process is scheduled to run when the device is opened and terminated (if still running) when the device is closed. It assumes that the resource allocation performed in gve_open() has taken place, and that the admin and transmit/receive data structure pointers are therefore valid. The process initialisation in gve_probe() erroneously calls process_init() rather than process_init_stopped() and will therefore schedule the startup process immediately, before the relevant resources have been allocated. This bug is masked in the typical use case of a Google Cloud instance with a single NIC built with the config/cloud/gce.ipxe embedded script, since the embedded script will immediately open the NIC (and therefore allocate the required resources) before the scheduled process is allowed to run for the first time. In a multi-NIC instance, undefined behaviour will arise as soon as the startup process for the second NIC is allowed to run. Fix by using process_init_stopped() to avoid implicitly scheduling the startup process during gve_probe(). Originally-fixed-by: Kal Cutter Conley <kalcutterc@nvidia.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Remove obsolete bigint_mod_multiply()Michael Brown2024-11-283-277/+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-285-29/+164
| | | | | | | | | | | | | | | | | 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-273-0/+174
| | | | | | | | | | 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-272-6/+11
| | | | | | | | | | | | 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-273-46/+65
| | | | | | | | | | 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-263-117/+72
| | | | | | | | | | | | | | | | 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-268-85/+140
| | | | | | | | 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-203-5/+30
| | | | | | | | 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>
* [efi] Ensure local drives are connected when attempting a SAN bootMichael Brown2024-11-201-0/+3
| | | | | | | | | | | | | | | UEFI systems may choose not to connect drivers for local disk drives when the boot policy is set to attempt a network boot. This may cause the "sanboot" command to be unable to boot from a local drive, since the relevant block device and filesystem drivers may not have been connected. Fix by ensuring that all available drivers are connected before attempting to boot from an EFI block device. Reported-by: Andrew Cottrell <andrew.cottrell@xtxmarkets.com> Tested-by: Andrew Cottrell <andrew.cottrell@xtxmarkets.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Allow for per-architecture cross-compilation prefixesMichael Brown2024-10-292-128/+139
| | | | | | | | | | | | | | | | | | | | | | | | | We currently require the variable CROSS (or CROSS_COMPILE) to be set to specify the global cross-compilation prefix. This becomes cumbersome when developing across multiple CPU architectures, requiring frequent editing of build command lines and preventing incompatible architectures from being built with a single command. Allow a default cross-compilation prefix for each architecture to be specified via the CROSS_COMPILE_<arch> variables. These may then be provided as environment variables, e.g. using export CROSS_COMPILE_arm32=arm-linux-gnu- export CROSS_COMPILE_arm64=aarch64-linux-gnu- export CROSS_COMPILE_loong64=loongarch64-linux-gnu- export CROSS_COMPILE_riscv32=riscv64-linux-gnu- export CROSS_COMPILE_riscv64=riscv64-linux-gnu- This change requires some portions of the Makefile to be rearranged, to allow for the fact that $(CROSS_COMPILE) may not have been set until the build directory has been parsed to determine the CPU architecture. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [riscv] Check if seed CSR is accessible from S-modeMichael Brown2024-10-282-0/+82
| | | | | | | | | | | | | The seed CSR defined by the Zkr extension is accessible only in M-mode by default. Older versions of OpenSBI (prior to version 1.4) do not set mseccfg.sseed, with the result that attempts to access the seed CSR from S-mode will raise an illegal instruction exception. Add a facility for testing the accessibility of arbitrary CSRs, and use it to check that the seed CSR is accessible before reporting the seed CSR entropy source as being functional. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [sbi] Add support for running as a RISC-V SBI payloadMichael Brown2024-10-2816-0/+532
| | | | | | | | | | | | | | | | | Add basic support for running directly on top of SBI, with no UEFI firmware present. Build as e.g.: make CROSS=riscv64-linux-gnu- bin-riscv64/ipxe.sbi The resulting binary can be tested in QEMU using e.g.: qemu-system-riscv64 -M virt -cpu max -serial stdio \ -kernel bin-riscv64/ipxe.sbi No drivers or executable binary formats are supported yet, but the unit test suite may be run successfully. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Allow default platform to vary by architectureMichael Brown2024-10-281-5/+12
| | | | | | | | | | | | | | | | | Restructure the parsing of the build directory name from bin[[-<arch>]-<platform>] to bin[-<arch>[-<platform>]] and allow for a per-architecture default build platform. For the sake of backwards compatibility, handle "bin-efi" as a special case equivalent to "bin-i386-efi". Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pci] Provide a null PCI API for platforms with no PCI busMichael Brown2024-10-283-0/+198
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [riscv] Add missing volatile qualifiers on timer and seed CSR accessesMichael Brown2024-10-282-9/+11
| | | | | | | | | | The timer and entropy seed CSRs will, by design, return different values each time they are read. Add the missing volatile qualifiers on the inline assembly to prevent gcc from assuming that repeated invocations may be elided. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [riscv] Add support for the seed CSR as an entropy sourceMichael Brown2024-10-283-0/+114
| | | | | | | | | The Zkr entropy source extension defines a potentially unprivileged seed CSR that can be read to obtain 16 bits of entropy input, with a mandated requirement that 256 entropy input bits read from the seed CSR will contain at least 128 bits of min-entropy. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [riscv] Add support for RDTIME as a timer sourceMichael Brown2024-10-283-0/+197
| | | | | | | | | | | | The Zicntr extension defines an unprivileged wall-clock time CSR that roughly matches the behaviour of an invariant TSC on x86. The nominal frequency of this timer may be read from the "timebase-frequency" property of the CPU node in the device tree. Add a timer source using RDTIME to provide implementations of udelay() and currticks(), modelled on the existing RDTSC-based timer for x86. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [riscv] Add support for checking CPU extensions reported via device treeMichael Brown2024-10-283-0/+117
| | | | | | | | | | | | | RISC-V seems to allow for direct discovery of CPU features only from M-mode (e.g. by setting up a trap handler and then attempting to access a CSR), with S-mode code expected to read the resulting constructed ISA description from the device tree. Add the ability to check for the presence of named extensions listed in the "riscv,isa" property of the device tree node corresponding to the boot hart. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [fdt] Add ability to parse unsigned integer propertiesMichael Brown2024-10-282-0/+39
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pci] Drag in PCI settings mechanism only when PCI support is presentMichael Brown2024-10-253-3/+42
| | | | | | | Allow for the existence of platforms with no PCI bus by including the PCI settings mechanism only if PCI bus support is included. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [uaccess] Rename UACCESS_EFI to UACCESS_FLATMichael Brown2024-10-254-118/+89
| | | | | | | | | 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-254-0/+67
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [riscv] Add support for reboot and power off via SBIMichael Brown2024-10-225-0/+120
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [riscv] Add support for the SBI debug consoleMichael Brown2024-10-225-0/+263
| | | | | | | | Add the ability to issue Supervisor Binary Interface (SBI) calls via the ECALL instruction, and use the SBI DBCN extension to implement a debug console. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Add bigint_mod_invert() to calculate inverse modulo a power of twoMichael Brown2024-10-213-0/+143
| | | | | | | | | | | | | | | | | 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-186-6/+191
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-176-2/+225
| | | | | | | | 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-153-37/+296
| | | | | | | | | | | 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>