lib/crypto: mips/chacha: Handle lengths of 2 GiB or more

The MIPS ChaCha assembly, which is chacha_crypt_arch() itself, tests
the remaining length with signed branches, so for 2 GiB + 64 bytes or
more it takes the final partial block path too early and processes less
than requested.  It is only used on 32-bit kernels, where size_t is 32
bits, so declaring the length as size_t does not avoid this.  No
in-tree caller passes such lengths.

The partial block code also keeps the remaining length as a negative
value, so instead of changing the assembly, rename it to
chacha_crypt_mips() and add a C chacha_crypt_arch() that passes it at
most 1 GiB per call.

Tested in QEMU user mode: with a length of 0xfffff045 the assembly
processed about 4 KiB and advanced the block counter by 64; with the
same 1 GiB loop in C, a 1.25 GiB + 4101 byte buffer matches a C
reference.  An LLM review of this code found the bug.

Assisted-by: LLM
Signed-off-by: Vladimir Kukharenko <vladimir@genproof.com>
Link: https://patch.msgid.link/20261014-libcrypto-chacha-32bit-2gib-v1-2-e0719ca0be89@genproof.com
Signed-off-by: Eric Biggers <ebiggers@kernel.org>

0 files changed, 0 insertions, 0 deletions