linux-kernel - Re: [PATCH v7 1/3] crypto: ti - Add support for AES-CTR in DTHEv2 driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <aWR4R8easn23zuHO@gondor.apana.org.au>
Date: Mon, 12 Jan 2026 12:27:51 +0800
From: Herbert Xu <herbert@...dor.apana.org.au>
To: T Pratham <t-pratham@...com>
Cc: "David S. Miller" <davem@...emloft.net>,
	Manorit Chawdhry <m-chawdhry@...com>,
	Kamlesh Gurudasani <kamlesh@...com>,
	Shiva Tripathi <s-tripathi1@...com>,
	Kavitha Malarvizhi <k-malarvizhi@...com>,
	Vishal Mahaveer <vishalm@...com>,
	Praneeth Bajjuri <praneeth@...com>, linux-crypto@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v7 1/3] crypto: ti - Add support for AES-CTR in DTHEv2
 driver

On Wed, Nov 26, 2025 at 04:46:15PM +0530, T Pratham wrote:
>
> @@ -295,6 +356,32 @@ static int dthe_aes_run(struct crypto_engine *engine, void *areq)
>  	aes_irqenable_val |= DTHE_AES_IRQENABLE_EN_ALL;
>  	writel_relaxed(aes_irqenable_val, aes_base_reg + DTHE_P_AES_IRQENABLE);
>  
> +	if (ctx->aes_mode == DTHE_AES_CTR) {
> +		/*
> +		 * CTR mode can operate on any input length, but the hardware
> +		 * requires input length to be a multiple of the block size.
> +		 * We need to handle the padding in the driver.
> +		 */
> +		if (req->cryptlen % AES_BLOCK_SIZE) {
> +			/* Need to create a new SG list with padding */
> +			pad_len = ALIGN(req->cryptlen, AES_BLOCK_SIZE) - req->cryptlen;
> +			memset(pad_buf, 0, pad_len);
> +
> +			src = dthe_chain_pad_sg(req->src, src_nents, src_pad, pad_buf, pad_len);
> +			src_nents++;

This is too complicated and may break if the user supplies an SG list
that's much longer than what is being encrypted.  For example, the
user could have an SG list spanning many pages, and only the first
of half of which are to be encrypted.  If you break it up here you
will risk corrupting the bigger SG list.

I think it's much simpler to just stop at the last block boundary,
and then do the last partial block manually with lib/crypto aes.

Cheers,
-- 
Email: Herbert Xu <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt