linux-kernel - Re: [PATCH 3/4 RESEND] crypto: octeontx2: Fix address alignment on CN10K A0/A1 and OcteonTX2

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <aCqzAQH06FAoYpYO@gondor.apana.org.au>
Date: Mon, 19 May 2025 12:26:41 +0800
From: Herbert Xu <herbert@...dor.apana.org.au>
To: Bharat Bhushan <bbhushan2@...vell.com>
Cc: bbrezillon@...nel.org, arno@...isbad.org, schalla@...vell.com,
	davem@...emloft.net, giovanni.cabiddu@...el.com, linux@...blig.org,
	linux-crypto@...r.kernel.org, linux-kernel@...r.kernel.org,
	bharatb.linux@...il.com, stable@...r.kernel.org
Subject: Re: [PATCH 3/4 RESEND] crypto: octeontx2: Fix address alignment on
 CN10K A0/A1 and OcteonTX2

On Wed, May 14, 2025 at 10:40:42AM +0530, Bharat Bhushan wrote:
>
> @@ -429,22 +431,50 @@ otx2_sg_info_create(struct pci_dev *pdev, struct otx2_cpt_req_info *req,
>  		return NULL;
>  	}
>  
> -	g_sz_bytes = ((req->in_cnt + 3) / 4) *
> -		      sizeof(struct otx2_cpt_sglist_component);
> -	s_sz_bytes = ((req->out_cnt + 3) / 4) *
> -		      sizeof(struct otx2_cpt_sglist_component);
> +	/* Allocate memory to meet below alignment requirement:
> +	 *  ----------------------------------
> +	 * |    struct otx2_cpt_inst_info     |
> +	 * |    (No alignment required)       |
> +	 * |     -----------------------------|
> +	 * |    | padding for 8B alignment    |
> +	 * |----------------------------------|
> +	 * |    SG List Gather/Input memory   |
> +	 * |    Length = multiple of 32Bytes  |
> +	 * |    Alignment = 8Byte             |
> +	 * |----------------------------------|
> +	 * |    SG List Scatter/Output memory |
> +	 * |    Length = multiple of 32Bytes  |
> +	 * |    Alignment = 8Byte             |
> +	 * |    (padding for below alignment) |
> +	 * |     -----------------------------|
> +	 * |    | padding for 32B alignment   |
> +	 * |----------------------------------|
> +	 * |    Result response memory        |
> +	 *  ----------------------------------
> +	 */
>  
> -	dlen = g_sz_bytes + s_sz_bytes + SG_LIST_HDR_SIZE;
> -	align_dlen = ALIGN(dlen, align);
> -	info_len = ALIGN(sizeof(*info), align);
> -	total_mem_len = align_dlen + info_len + sizeof(union otx2_cpt_res_s);
> +	info_len = sizeof(*info);
> +
> +	g_len = ((req->in_cnt + 3) / 4) *
> +		 sizeof(struct otx2_cpt_sglist_component);
> +	s_len = ((req->out_cnt + 3) / 4) *
> +		 sizeof(struct otx2_cpt_sglist_component);
> +
> +	dlen = g_len + s_len + SG_LIST_HDR_SIZE;
> +
> +	/* Allocate extra memory for SG and response address alignment */
> +	total_mem_len = ALIGN(info_len, OTX2_CPT_DPTR_RPTR_ALIGN) + dlen;
> +	total_mem_len = ALIGN(total_mem_len, OTX2_CPT_RES_ADDR_ALIGN) +
> +			 sizeof(union otx2_cpt_res_s);

This doesn't look right.  It would be correct if kzalloc returned
a 32-byte aligned pointer to start with.  But it doesn't anymore,
which is why you're making this patch in the first place :)

So you need to add extra memory to bridge the gap between what it
returns and what you expect.  Since it returns 8-byte aligned
memory, and you expect 32-byte aligned pointers, you should add
24 bytes.

IOW the calculation should be:

	total_mem_len = ALIGN(info_len, OTX2_CPT_DPTR_RPTR_ALIGN) + dlen;
	total_mem_len = ALIGN(total_mem_len, OTX2_CPT_DPTR_RPTR_ALIGN);
	total_mem_len += (OTX2_CPT_RES_ADDR_ALIGN - 1) &
			 ~(OTX2_CPT_DPTR_RPTR_ALIGN - 1);

>  	info = kzalloc(total_mem_len, gfp);
>  	if (unlikely(!info))
>  		return NULL;
>  
>  	info->dlen = dlen;
> -	info->in_buffer = (u8 *)info + info_len;
> +	info->in_buffer = PTR_ALIGN((u8 *)info + info_len,
> +				    OTX2_CPT_DPTR_RPTR_ALIGN);
> +	info->out_buffer = info->in_buffer + 8 + g_len;

I presume the 8 here corresponds to SG_LIST_HDR_SIZE from the dlen
calculation above.  If so please spell it out as otherwise it's just
confusing.

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