linux-kernel - Re: [PATCH v3 2/6] drivers: crypto: qce: sha: Hold back a block of data to be transferred as part of final

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: <YA7vf9ilbeI9fskA@builder.lan>
Date:   Mon, 25 Jan 2021 10:19:11 -0600
From:   Bjorn Andersson <bjorn.andersson@...aro.org>
To:     Thara Gopinath <thara.gopinath@...aro.org>
Cc:     herbert@...dor.apana.org.au, davem@...emloft.net,
        ebiggers@...gle.com, ardb@...nel.org, sivaprak@...eaurora.org,
        linux-crypto@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 2/6] drivers: crypto: qce: sha: Hold back a block of
 data to be transferred as part of final

On Wed 20 Jan 12:48 CST 2021, Thara Gopinath wrote:

> If the available data to transfer is exactly a multiple of block size, save
> the last block to be transferred in qce_ahash_final (with the last block
> bit set) if this is indeed the end of data stream. If not this saved block
> will be transferred as part of next update. If this block is not held back
> and if this is indeed the end of data stream, the digest obtained will be
> wrong since qce_ahash_final will see that rctx->buflen is 0 and return
> doing nothing which in turn means that a digest will not be copied to the
> destination result buffer.  qce_ahash_final cannot be made to alter this
> behavior and allowed to proceed if rctx->buflen is 0 because the crypto
> engine BAM does not allow for zero length transfers.
> 

Please drop "drivers: " from $subject.

Apart from that this looks good.

Reviewed-by: Bjorn Andersson <bjorn.andersson@...aro.org>

Regards,
Bjorn

> Signed-off-by: Thara Gopinath <thara.gopinath@...aro.org>
> ---
>  drivers/crypto/qce/sha.c | 19 +++++++++++++++++++
>  1 file changed, 19 insertions(+)
> 
> diff --git a/drivers/crypto/qce/sha.c b/drivers/crypto/qce/sha.c
> index 08aed03e2b59..dd263c5e4dd8 100644
> --- a/drivers/crypto/qce/sha.c
> +++ b/drivers/crypto/qce/sha.c
> @@ -216,6 +216,25 @@ static int qce_ahash_update(struct ahash_request *req)
>  
>  	/* calculate how many bytes will be hashed later */
>  	hash_later = total % blocksize;
> +
> +	/*
> +	 * At this point, there is more than one block size of data.  If
> +	 * the available data to transfer is exactly a multiple of block
> +	 * size, save the last block to be transferred in qce_ahash_final
> +	 * (with the last block bit set) if this is indeed the end of data
> +	 * stream. If not this saved block will be transferred as part of
> +	 * next update. If this block is not held back and if this is
> +	 * indeed the end of data stream, the digest obtained will be wrong
> +	 * since qce_ahash_final will see that rctx->buflen is 0 and return
> +	 * doing nothing which in turn means that a digest will not be
> +	 * copied to the destination result buffer.  qce_ahash_final cannot
> +	 * be made to alter this behavior and allowed to proceed if
> +	 * rctx->buflen is 0 because the crypto engine BAM does not allow
> +	 * for zero length transfers.
> +	 */
> +	if (!hash_later)
> +		hash_later = blocksize;
> +
>  	if (hash_later) {
>  		unsigned int src_offset = req->nbytes - hash_later;
>  		scatterwalk_map_and_copy(rctx->buf, req->src, src_offset,
> -- 
> 2.25.1
>