Linux cryptographic layer development
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Linux Crypto Mailing List <linux-crypto@vger.kernel.org>
Subject: Re: [v2 PATCH 2/2] crypto: hash - Use nth_page instead of doing it by hand
Date: Wed, 12 Mar 2025 13:09:08 -0700	[thread overview]
Message-ID: <20250312200908.GB1621@sol.localdomain> (raw)
In-Reply-To: <a68366725ab6130fea3a5e3257e92c8109b7f86a.1741753576.git.herbert@gondor.apana.org.au>

On Wed, Mar 12, 2025 at 12:30:00PM +0800, Herbert Xu wrote:
> Use nth_page instead of adding n to the page pointer.
> 
> This also fixes a real bug in shash_ahash_digest where the the
> check for continguous hash data may be incorrect in the presence
> of highmem.  This could result in an incorrect hash or worse.

Again, you need to explain this properly.

It seems that the "real bug" mentioned above is the case of
scatterlist::offset > PAGE_SIZE.  That's unrelated to the nth_page() fix, which
seems to be for scatterlist elements that span physical memory sections.  Also,
unlike the case of scatterlist elements that span physical memory sections,
scatterlist::offset > PAGE_SIZE can be easily tested.  The self-tests need to be
updated to test that case, if it's indeed now established that it's allowed.

Note that there is also page arithmetic being done in scatterwalk_done_dst() and
scomp_acomp_comp_decomp().  Those presumably need the nth_page() fix too.

scomp_acomp_comp_decomp() also assumes that if the first page in a given
scatterlist element is lowmem, then any additional pages are lowmem too.  That
sounds like another potentially wrong assumption.  Can scatterlist elements span
memory zones?  Or just physical memory sections?

Is there actually going to be a clear specification of the scatterlist based
crypto APIs, or just random broken and incomplete fixes?

> @@ -201,25 +202,36 @@ int shash_ahash_digest(struct ahash_request *req, struct shash_desc *desc)
>  	unsigned int nbytes = req->nbytes;
>  	struct scatterlist *sg;
>  	unsigned int offset;
> +	struct page *page;
> +	const u8 *data;
>  	int err;
>  
> -	if (ahash_request_isvirt(req))
> -		return crypto_shash_digest(desc, req->svirt, nbytes,
> -					   req->result);
> +	data = req->svirt;
> +	if (!nbytes || ahash_request_isvirt(req))
> +		return crypto_shash_digest(desc, data, nbytes, req->result);
>  
> -	if (nbytes &&
> -	    (sg = req->src, offset = sg->offset,
> -	     nbytes <= min(sg->length, ((unsigned int)(PAGE_SIZE)) - offset))) {
> -		void *data;
> +	sg = req->src;
> +	if (nbytes > sg->length)
> +		return crypto_shash_init(desc) ?:
> +		       shash_ahash_finup(req, desc);
>  
> -		data = kmap_local_page(sg_page(sg));
> -		err = crypto_shash_digest(desc, data + offset, nbytes,
> -					  req->result);
> -		kunmap_local(data);
> -	} else
> -		err = crypto_shash_init(desc) ?:
> -		      shash_ahash_finup(req, desc);
> +	page = sg_page(sg);
> +	data = lowmem_page_address(page) + offset;
> +	if (!IS_ENABLED(CONFIG_HIGHMEM))
> +		return crypto_shash_digest(desc, data, nbytes, req->result);
>  
> +	offset = sg->offset;
> +	page = nth_page(page, offset >> PAGE_SHIFT);
> +	offset = offset_in_page(offset);
> +
> +	if (nbytes > (unsigned int)PAGE_SIZE - offset)
> +		return crypto_shash_init(desc) ?:
> +		       shash_ahash_finup(req, desc);
> +
> +	data = kmap_local_page(page);
> +	err = crypto_shash_digest(desc, data + offset, nbytes,
> +				  req->result);
> +	kunmap_local(data);
>  	return err;
>  }
>  EXPORT_SYMBOL_GPL(shash_ahash_digest);

This is clearly untested, so not much point in reviewing it.

- Eric

  reply	other threads:[~2025-03-12 20:09 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-12  4:29 [v2 PATCH 0/2] crypto: Use nth_page instead of doing it by hand Herbert Xu
2025-03-12  4:29 ` [v2 PATCH 1/2] crypto: scatterwalk - " Herbert Xu
2025-03-12 19:56   ` Eric Biggers
2025-03-13  1:43     ` Herbert Xu
2025-03-13  3:13       ` Eric Biggers
2025-03-12  4:30 ` [v2 PATCH 2/2] crypto: hash " Herbert Xu
2025-03-12 20:09   ` Eric Biggers [this message]
2025-03-13  2:36     ` Herbert Xu
2025-03-13  3:07       ` Eric Biggers
2025-03-13  4:04         ` Herbert Xu

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=20250312200908.GB1621@sol.localdomain \
    --to=ebiggers@kernel.org \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-crypto@vger.kernel.org \
    /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