All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: linux-crypto@vger.kernel.org, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org, Danny Tsen <dtsen@linux.ibm.com>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Naveen N Rao <naveen@kernel.org>,
	Nicholas Piggin <npiggin@gmail.com>,
	linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH v2 10/29] crypto: powerpc/p10-aes-gcm - simplify handling of linear associated data
Date: Thu, 2 Jan 2025 17:24:44 +0000	[thread overview]
Message-ID: <20250102172444.GB49952@google.com> (raw)
In-Reply-To: <ec3515f1-f93a-4520-a9da-6ad14f9a6fe0@csgroup.eu>

On Thu, Jan 02, 2025 at 12:50:50PM +0100, Christophe Leroy wrote:
> 
> 
> Le 30/12/2024 à 01:13, Eric Biggers a écrit :
> > From: Eric Biggers <ebiggers@google.com>
> > 
> > p10_aes_gcm_crypt() is abusing the scatter_walk API to get the virtual
> > address for the first source scatterlist element.  But this code is only
> > built for PPC64 which is a !HIGHMEM platform, and it can read past a
> > page boundary from the address returned by scatterwalk_map() which means
> > it already assumes the address is from the kernel's direct map.  Thus,
> > just use sg_virt() instead to get the same result in a simpler way.
> > 
> > Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
> > Cc: Danny Tsen <dtsen@linux.ibm.com>
> > Cc: Michael Ellerman <mpe@ellerman.id.au>
> > Cc: Naveen N Rao <naveen@kernel.org>
> > Cc: Nicholas Piggin <npiggin@gmail.com>
> > Cc: linuxppc-dev@lists.ozlabs.org
> > Signed-off-by: Eric Biggers <ebiggers@google.com>
> > ---
> > 
> > This patch is part of a long series touching many files, so I have
> > limited the Cc list on the full series.  If you want the full series and
> > did not receive it, please retrieve it from lore.kernel.org.
> > 
> >   arch/powerpc/crypto/aes-gcm-p10-glue.c | 8 ++------
> >   1 file changed, 2 insertions(+), 6 deletions(-)
> > 
> > diff --git a/arch/powerpc/crypto/aes-gcm-p10-glue.c b/arch/powerpc/crypto/aes-gcm-p10-glue.c
> > index f37b3d13fc53..2862c3cf8e41 100644
> > --- a/arch/powerpc/crypto/aes-gcm-p10-glue.c
> > +++ b/arch/powerpc/crypto/aes-gcm-p10-glue.c
> > @@ -212,11 +212,10 @@ static int p10_aes_gcm_crypt(struct aead_request *req, u8 *riv,
> >   	struct p10_aes_gcm_ctx *ctx = crypto_tfm_ctx(tfm);
> >   	u8 databuf[sizeof(struct gcm_ctx) + PPC_ALIGN];
> >   	struct gcm_ctx *gctx = PTR_ALIGN((void *)databuf, PPC_ALIGN);
> >   	u8 hashbuf[sizeof(struct Hash_ctx) + PPC_ALIGN];
> >   	struct Hash_ctx *hash = PTR_ALIGN((void *)hashbuf, PPC_ALIGN);
> > -	struct scatter_walk assoc_sg_walk;
> >   	struct skcipher_walk walk;
> >   	u8 *assocmem = NULL;
> >   	u8 *assoc;
> >   	unsigned int cryptlen = req->cryptlen;
> >   	unsigned char ivbuf[AES_BLOCK_SIZE+PPC_ALIGN];
> > @@ -232,12 +231,11 @@ static int p10_aes_gcm_crypt(struct aead_request *req, u8 *riv,
> >   	memset(ivbuf, 0, sizeof(ivbuf));
> >   	memcpy(iv, riv, GCM_IV_SIZE);
> >   	/* Linearize assoc, if not already linear */
> >   	if (req->src->length >= assoclen && req->src->length) {
> > -		scatterwalk_start(&assoc_sg_walk, req->src);
> > -		assoc = scatterwalk_map(&assoc_sg_walk);
> > +		assoc = sg_virt(req->src); /* ppc64 is !HIGHMEM */
> >   	} else {
> >   		gfp_t flags = (req->base.flags & CRYPTO_TFM_REQ_MAY_SLEEP) ?
> >   			      GFP_KERNEL : GFP_ATOMIC;
> >   		/* assoc can be any length, so must be on heap */
> > @@ -251,13 +249,11 @@ static int p10_aes_gcm_crypt(struct aead_request *req, u8 *riv,
> >   	vsx_begin();
> >   	gcmp10_init(gctx, iv, (unsigned char *) &ctx->enc_key, hash, assoc, assoclen);
> >   	vsx_end();
> > -	if (!assocmem)
> > -		scatterwalk_unmap(assoc);
> > -	else
> > +	if (assocmem)
> >   		kfree(assocmem);
> 
> kfree() accepts a NULL pointer, you can call kfree(assocmem) without 'if
> (assocmem)'

The existing code did that too, but sure I'll change that in v3.

- Eric

  reply	other threads:[~2025-01-02 17:24 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-30  0:13 [PATCH v2 00/29] crypto: scatterlist handling improvements Eric Biggers
2024-12-30  0:13 ` [PATCH v2 01/29] crypto: skcipher - document skcipher_walk_done() and rename some vars Eric Biggers
2024-12-30  0:13 ` [PATCH v2 02/29] crypto: skcipher - remove unnecessary page alignment of bounce buffer Eric Biggers
2024-12-30  0:13 ` [PATCH v2 03/29] crypto: skcipher - remove redundant clamping to page size Eric Biggers
2024-12-30  0:13 ` [PATCH v2 04/29] crypto: skcipher - remove redundant check for SKCIPHER_WALK_SLOW Eric Biggers
2024-12-30  0:13 ` [PATCH v2 05/29] crypto: skcipher - fold skcipher_walk_skcipher() into skcipher_walk_virt() Eric Biggers
2024-12-30  0:13 ` [PATCH v2 06/29] crypto: skcipher - clean up initialization of skcipher_walk::flags Eric Biggers
2024-12-30  0:13 ` [PATCH v2 07/29] crypto: skcipher - optimize initializing skcipher_walk fields Eric Biggers
2024-12-30  0:13 ` [PATCH v2 08/29] crypto: skcipher - call cond_resched() directly Eric Biggers
2024-12-30  0:13 ` [PATCH v2 09/29] crypto: omap - switch from scatter_walk to plain offset Eric Biggers
2024-12-30  0:13 ` [PATCH v2 10/29] crypto: powerpc/p10-aes-gcm - simplify handling of linear associated data Eric Biggers
2025-01-02 11:50   ` Christophe Leroy
2025-01-02 17:24     ` Eric Biggers [this message]
2024-12-30  0:14 ` [PATCH v2 11/29] crypto: scatterwalk - move to next sg entry just in time Eric Biggers
2024-12-30  0:14 ` [PATCH v2 12/29] crypto: scatterwalk - add new functions for skipping data Eric Biggers
2024-12-30  0:14 ` [PATCH v2 13/29] crypto: scatterwalk - add new functions for iterating through data Eric Biggers
2024-12-30  0:14 ` [PATCH v2 14/29] crypto: scatterwalk - add new functions for copying data Eric Biggers
2024-12-30  0:14 ` [PATCH v2 15/29] crypto: scatterwalk - add scatterwalk_get_sglist() Eric Biggers
2024-12-30  0:14 ` [PATCH v2 16/29] crypto: skcipher - use scatterwalk_start_at_pos() Eric Biggers
2024-12-30  0:14 ` [PATCH v2 17/29] crypto: aegis - use the new scatterwalk functions Eric Biggers
2024-12-30  0:14 ` [PATCH v2 18/29] crypto: arm/ghash " Eric Biggers
2024-12-30  0:14 ` [PATCH v2 19/29] crypto: arm64 " Eric Biggers
2024-12-30  0:14 ` [PATCH v2 20/29] crypto: nx " Eric Biggers
2024-12-30  0:14 ` [PATCH v2 21/29] crypto: s390/aes-gcm " Eric Biggers
2025-01-08 15:06   ` Harald Freudenberger
2024-12-30  0:14 ` [PATCH v2 22/29] crypto: s5p-sss " Eric Biggers
2024-12-30  0:14 ` [PATCH v2 23/29] crypto: stm32 " Eric Biggers
2024-12-30  0:14 ` [PATCH v2 24/29] crypto: x86/aes-gcm " Eric Biggers
2024-12-30  0:14 ` [PATCH v2 25/29] crypto: x86/aegis " Eric Biggers
2024-12-30  0:14 ` [PATCH v2 26/29] net/tls: " Eric Biggers
2024-12-30  0:14 ` [PATCH v2 27/29] crypto: skcipher - " Eric Biggers
2024-12-30  0:14 ` [PATCH v2 28/29] crypto: scatterwalk - remove obsolete functions Eric Biggers
2024-12-30  0:14 ` [PATCH v2 29/29] crypto: scatterwalk - don't split at page boundaries when !HIGHMEM Eric Biggers
2024-12-30  1:31 ` [PATCH v2 00/29] crypto: scatterlist handling improvements 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=20250102172444.GB49952@google.com \
    --to=ebiggers@kernel.org \
    --cc=christophe.leroy@csgroup.eu \
    --cc=dtsen@linux.ibm.com \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mpe@ellerman.id.au \
    --cc=naveen@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=npiggin@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.