All of lore.kernel.org
 help / color / mirror / Atom feed
From: Harald Freudenberger <freude@linux.ibm.com>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
	Holger Dengler <dengler@linux.ibm.com>,
	Ingo Franzki <ifranzki@linux.ibm.com>
Subject: Re: [PATCH] crypto: ahash - Add support for drivers with no fallback
Date: Thu, 05 Jun 2025 15:29:00 +0200	[thread overview]
Message-ID: <c38cecabd936e4fae1ae4639dec3d1ea@linux.ibm.com> (raw)
In-Reply-To: <aEAX4c2vU46HlBjG@gondor.apana.org.au>

On 2025-06-04 11:54, Herbert Xu wrote:
> On Tue, Jun 03, 2025 at 03:49:16PM +0200, Harald Freudenberger wrote:
>> Hello Herbert
>> 
>> I am facing a weird issue with my phmac implementation since kernel 
>> 5.15 has
>> been released. The algorithm registers fine but obviously it is not
>> self-tested
>> and thus you can't access it via AF_ALG or with an in-kernel customer.
> 
> So the issue is that this algorithm cannot have a fallback, because
> the key is held in hardware only.
> 
> Please try the following patch and set the bit CRYPTO_ALG_NO_FALLBACK
> and see if it works.
> 
> Thanks,
> 
> ---8<---
> Some drivers cannot have a fallback, e.g., because the key is held
> in hardwre.  Allow these to be used with ahash by adding the bit
> CRYPTO_ALG_NO_FALLBACK.
> 
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
> 
> diff --git a/crypto/ahash.c b/crypto/ahash.c
> index e10bc2659ae4..bd9e49950201 100644
> --- a/crypto/ahash.c
> +++ b/crypto/ahash.c
> @@ -347,6 +347,9 @@ static int ahash_do_req_chain(struct ahash_request 
> *req,
>  	if (crypto_ahash_statesize(tfm) > HASH_MAX_STATESIZE)
>  		return -ENOSYS;
> 
> +	if (!crypto_ahash_need_fallback(tfm))
> +		return -ENOSYS;
> +
>  	{
>  		u8 state[HASH_MAX_STATESIZE];
> 
> @@ -952,6 +955,10 @@ static int ahash_prepare_alg(struct ahash_alg 
> *alg)
>  	    base->cra_reqsize > MAX_SYNC_HASH_REQSIZE)
>  		return -EINVAL;
> 
> +	if (base->cra_flags & CRYPTO_ALG_NEED_FALLBACK &&
> +	    base->cra_flags & CRYPTO_ALG_NO_FALLBACK)
> +		return -EINVAL;
> +
>  	err = hash_prepare_alg(&alg->halg);
>  	if (err)
>  		return err;
> @@ -960,7 +967,8 @@ static int ahash_prepare_alg(struct ahash_alg *alg)
>  	base->cra_flags |= CRYPTO_ALG_TYPE_AHASH;
> 
>  	if ((base->cra_flags ^ CRYPTO_ALG_REQ_VIRT) &
> -	    (CRYPTO_ALG_ASYNC | CRYPTO_ALG_REQ_VIRT))
> +	    (CRYPTO_ALG_ASYNC | CRYPTO_ALG_REQ_VIRT) &&
> +	    !(base->cra_flags & CRYPTO_ALG_NO_FALLBACK))
>  		base->cra_flags |= CRYPTO_ALG_NEED_FALLBACK;
> 
>  	if (!alg->setkey)
> diff --git a/include/linux/crypto.h b/include/linux/crypto.h
> index b50f1954d1bb..a2137e19be7d 100644
> --- a/include/linux/crypto.h
> +++ b/include/linux/crypto.h
> @@ -136,6 +136,9 @@
>  /* Set if the algorithm supports virtual addresses. */
>  #define CRYPTO_ALG_REQ_VIRT		0x00040000
> 
> +/* Set if the algorithm cannot have a fallback (e.g., phmac). */
> +#define CRYPTO_ALG_NO_FALLBACK		0x00080000
> +
>  /* The high bits 0xff000000 are reserved for type-specific flags. */
> 
>  /*

Works perfect - tested on a fresh clone of cryptodev-2.6 with my
phmac v12 patches on top.
Add a Tested-by: Harald Freudenberger <freude@linux.ibm.com>
Please push into next, maybe fix the typo "hardwre" -> "hardware"
Thanks





  reply	other threads:[~2025-06-05 13:29 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-02  5:30 [v2 PATCH 0/9] crypto: sha256 - Use partial block API Herbert Xu
2025-05-02  5:30 ` [v2 PATCH 1/9] crypto: lib/sha256 - Add helpers for block-based shash Herbert Xu
2025-06-03  4:56   ` [v2 PATCH 1/9] crypto: lib/sha256 - Add helpers for block-based shash (RT build failure) Guenter Roeck
2025-06-03  4:59     ` Herbert Xu
2025-06-03  5:44       ` Guenter Roeck
2025-06-03 13:49   ` Regression: hash - Add HASH_REQUEST_ON_STACK causes asynch hashes to fail Harald Freudenberger
2025-06-04  9:54     ` [PATCH] crypto: ahash - Add support for drivers with no fallback Herbert Xu
2025-06-05 13:29       ` Harald Freudenberger [this message]
2025-06-11  3:07         ` Herbert Xu
2025-05-02  5:30 ` [v2 PATCH 2/9] crypto: sha256 - Use the partial block API for generic Herbert Xu
2025-05-02  5:30 ` [v2 PATCH 3/9] crypto: arch/sha256 - Export block functions as GPL only Herbert Xu
2025-05-02  5:31 ` [v2 PATCH 4/9] crypto: arm/sha256 - Add simd block function Herbert Xu
2025-05-02  5:31 ` [v2 PATCH 5/9] crypto: arm64/sha256 " Herbert Xu
2025-05-02  5:31 ` [v2 PATCH 6/9] crypto: riscv/sha256 " Herbert Xu
2025-05-02  5:31 ` [v2 PATCH 7/9] crypto: x86/sha256 " Herbert Xu
2025-05-02  5:31 ` [v2 PATCH 8/9] crypto: lib/sha256 - Use generic block helper Herbert Xu
2025-05-02  5:31 ` [v2 PATCH 9/9] crypto: sha256 - Use the partial block API 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=c38cecabd936e4fae1ae4639dec3d1ea@linux.ibm.com \
    --to=freude@linux.ibm.com \
    --cc=dengler@linux.ibm.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=ifranzki@linux.ibm.com \
    --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 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.