linux-kernel - Re: [PATCH v8 2/4] crypto: spacc

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

Message-ID: <CALxtO0=LxXg6Cw+PKnPQLhurkPRxvTOn63pyK9gFFH=y+F=hBQ@mail.gmail.com>
Date: Fri, 21 Nov 2025 13:30:57 +0530
From: Pavitrakumar Managutte <pavitrakumarm@...avyalabs.com>
To: Herbert Xu <herbert@...dor.apana.org.au>
Cc: linux-crypto@...r.kernel.org, linux-kernel@...r.kernel.org, 
	devicetree@...r.kernel.org, robh@...nel.org, krzk+dt@...nel.org, 
	conor+dt@...nel.org, Ruud.Derwig@...opsys.com, 
	manjunath.hadli@...avyalabs.com, adityak@...avyalabs.com, 
	Bhoomika Kadabi <bhoomikak@...avyalabs.com>
Subject: Re: [PATCH v8 2/4] crypto: spacc - Add SPAcc ahash support

Hi Herbert,

Thank you for your suggestion regarding removing dynamic statesize and
reqsize usage in the spacc_ahash driver. I reviewed the
aspeed_ahash_fallback implementation as you recommended and updated
our driver to follow the same approach, including using the
HASH_FBREQ_ON_STACK macro.

With these changes, the ahash self-tests and functional tests pass
successfully on kernel 6.17-rc1. However, the same implementation is
failing on 6.18-rc1. Since aspeed_ahash_fallback is currently the only
reference driver using this new fallback method, we wanted to request
a bit more insight into the expected usage patterns.

Specifically, it would be helpful to understand:

Whether there were any additional changes in the ahash API or fallback
handling between 6.17-rc1 and 6.18-rc1 that drivers should adapt to.

Any constraints or assumptions the new fallback mechanism requires,
beyond what aspeed_ahash_fallback demonstrates.

Whether the stack-based fallback request (HASH_FBREQ_ON_STACK) has any
new limitations or expected ordering requirements in 6.18-rc1.

We want to ensure our implementation aligns fully with the intended
direction of the API, so any guidance would be appreciated.

Warm regards,
PK

On Thu, Nov 6, 2025 at 11:53 AM Herbert Xu <herbert@...dor.apana.org.au> wrote:
>
> On Fri, Oct 31, 2025 at 10:18:01AM +0530, Pavitrakumar Managutte wrote:
> >
> > +static int spacc_hash_init_tfm(struct crypto_ahash *tfm)
> > +{
> > +     const struct spacc_alg *salg = container_of(crypto_ahash_alg(tfm),
> > +                                                 struct spacc_alg,
> > +                                                 alg.hash.base);
> > +     struct spacc_crypto_ctx *tctx = crypto_ahash_ctx(tfm);
> > +
> > +     tctx->handle    = -1;
> > +     tctx->ctx_valid = false;
> > +     tctx->dev       = get_device(salg->dev);
> > +
> > +     tctx->fb.hash = crypto_alloc_ahash(crypto_ahash_alg_name(tfm), 0,
> > +                     CRYPTO_ALG_NEED_FALLBACK);
> > +     if (IS_ERR(tctx->fb.hash)) {
> > +             dev_err(tctx->dev, "SPAcc ahash fallback tfm is NULL!\n");
> > +             put_device(tctx->dev);
> > +             return PTR_ERR(tctx->fb.hash);
> > +     }
> > +
> > +     crypto_ahash_set_statesize(tfm,
> > +                     crypto_ahash_statesize(tctx->fb.hash));
> > +
> > +     crypto_ahash_set_reqsize(tfm,
> > +                     sizeof(struct spacc_crypto_reqctx) +
> > +                     crypto_ahash_reqsize(tctx->fb.hash));
>
> Please stop using dynamic statesize/reqsize values as they are
> being phased out.
>
> The API now provides a fallback directly that can be used with
> a stack request.  Grep for aspeed_ahash_fallback to see an example
> of that being used.
>
> Thanks,
> --
> 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