openslx-ng/ipxe.git/src/arch/loong64, branch openslx

[build] Allow for 32-bit and 64-bit versions of util/zbin

2025-05-06T11:11:02+00:00

Parsing ELF data is simpler if we don't have to build a single binary to handle both 32-bit and 64-bit ELF formats. Allow for separate 32-bit and 64-bit binaries built from util/zbin.c (as is already done for util/elf2efi.c). Signed-off-by: Michael Brown

[crypto] Expose shifted out bit from big integer shifts

2025-02-13T15:25:35+00:00

Expose the bit shifted out as a result of shifting a big integer left or right. Signed-off-by: Michael Brown

[crypto] Expose carry flag from big integer addition and subtraction

2024-11-26T12:55:13+00:00

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

[crypto] Use architecture-independent bigint_is_set()

2024-10-10T14:35:16+00:00

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

[crypto] Rename bigint_rol()/bigint_ror() to bigint_shl()/bigint_shr()

2024-10-07T12:13:43+00:00

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

[crypto] Eliminate temporary carry space for big integer multiplication

2024-09-27T12:51:24+00:00

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

[profile] Standardise return type of profile_timestamp()

2024-09-24T14:40:45+00:00

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

[crypto] Use constant-time big integer multiplication

2024-09-23T12:19:58+00:00

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

[efi] Remove redundant EFI_BOOT_FILE definitions

2024-09-16T10:04:52+00:00

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 Signed-off-by: Michael Brown

[efi] Centralise definition of efi_cpu_nap()

2024-09-13T13:38:23+00:00

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