mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Vladimir Kukharenko via B4 Relay <devnull+vladimir.genproof.com@kernel.org>
To: Eric Biggers <ebiggers@kernel.org>,
	 "Jason A. Donenfeld" <Jason@zx2c4.com>,
	Ard Biesheuvel <ardb@kernel.org>
Cc: linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org,
	 linux-arm-kernel@lists.infradead.org,
	linux-mips@vger.kernel.org,
	 Vladimir Kukharenko <vladimir@genproof.com>
Subject: [PATCH 2/2] lib/crypto: mips/chacha: Handle lengths of 2 GiB or more
Date: Wed, 14 Oct 2026 20:34:22 +0000	[thread overview]
Message-ID: <20261014-libcrypto-chacha-32bit-2gib-v1-2-e0719ca0be89@genproof.com> (raw)
In-Reply-To: <20261014-libcrypto-chacha-32bit-2gib-v1-0-e0719ca0be89@genproof.com>

From: Vladimir Kukharenko <vladimir@genproof.com>

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>
---
 lib/crypto/mips/chacha-core.S |  8 ++++----
 lib/crypto/mips/chacha.h      | 20 +++++++++++++++++++-
 2 files changed, 23 insertions(+), 5 deletions(-)

diff --git a/lib/crypto/mips/chacha-core.S b/lib/crypto/mips/chacha-core.S
index 706aeb850fb0..1a2253d91af7 100644
--- a/lib/crypto/mips/chacha-core.S
+++ b/lib/crypto/mips/chacha-core.S
@@ -196,9 +196,9 @@ CONCAT3(.Lchacha_mips_xor_aligned_, PLUS_ONE(x), _b: ;) \
 .text
 .set	reorder
 .set	noat
-.globl	chacha_crypt_arch
-.ent	chacha_crypt_arch
-chacha_crypt_arch:
+.globl	chacha_crypt_mips
+.ent	chacha_crypt_mips
+chacha_crypt_mips:
 	.frame	$sp, STACK_SIZE, $ra
 
 	/* Load number of rounds */
@@ -414,7 +414,7 @@ chacha_crypt_arch:
 
 	/* Jump table */
 	FOR_EACH_WORD(JMPTBL_UNALIGNED)
-.end chacha_crypt_arch
+.end chacha_crypt_mips
 .set at
 
 /* Input arguments
diff --git a/lib/crypto/mips/chacha.h b/lib/crypto/mips/chacha.h
index 5a565d0a8c26..15b39c744c28 100644
--- a/lib/crypto/mips/chacha.h
+++ b/lib/crypto/mips/chacha.h
@@ -6,8 +6,26 @@
  */
 
 #include <linux/kernel.h>
+#include <linux/sizes.h>
 
-asmlinkage void chacha_crypt_arch(struct chacha_state *state, u8 *dst,
+asmlinkage void chacha_crypt_mips(struct chacha_state *state, u8 *dst,
 				  const u8 *src, size_t bytes, int nrounds);
 asmlinkage void hchacha_block_arch(const struct chacha_state *state,
 				   u32 out[HCHACHA_OUT_WORDS], int nrounds);
+
+static void chacha_crypt_arch(struct chacha_state *state, u8 *dst,
+			      const u8 *src, size_t bytes, int nrounds)
+{
+	/*
+	 * chacha_crypt_mips() compares the length as a signed value, so pass
+	 * it at most 1 GiB at a time.
+	 */
+	do {
+		size_t todo = min(bytes, SZ_1G);
+
+		chacha_crypt_mips(state, dst, src, todo, nrounds);
+		bytes -= todo;
+		src += todo;
+		dst += todo;
+	} while (bytes);
+}

-- 
2.43.0



  parent reply	other threads:[~2026-10-14 20:39 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-14 20:34 [PATCH 0/2] lib/crypto: chacha: Handle lengths of 2 GiB or more on 32-bit arm and MIPS Vladimir Kukharenko via B4 Relay
2026-10-14 20:34 ` [PATCH 1/2] lib/crypto: arm/chacha: Handle lengths of 2 GiB or more in scalar code Vladimir Kukharenko via B4 Relay
2026-10-14 20:34 ` Vladimir Kukharenko via B4 Relay [this message]
2026-10-16  7:28 ` [PATCH 0/2] lib/crypto: chacha: Handle lengths of 2 GiB or more on 32-bit arm and MIPS Eric Biggers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20261014-libcrypto-chacha-32bit-2gib-v1-2-e0719ca0be89@genproof.com \
    --to=devnull+vladimir.genproof.com@kernel.org \
    --cc=Jason@zx2c4.com \
    --cc=ardb@kernel.org \
    --cc=ebiggers@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=vladimir@genproof.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®