On Wed, Sep 25, 2024 at 4:27 AM Eric Biggers <ebiggers@xxxxxxxxxx> wrote:
>
> On Mon, Sep 23, 2024 at 12:39:11PM +0530, Harsh Jain wrote:
> > Hi All,
> >
> > We have observed self test failure with hmac(versal-sha3-384) in
> > init_tfm callback.
> >
> > [ 14.672021] WARNING: CPU: 1 PID: 578 at crypto/shash.c:495
> > crypto_shash_init_tfm+0xac/0xd0
> >
> > In init_tfm ("versal-sha3-384") we increase the descsize with
> > crypto_shash_descsize("sha3-384-generic") . When HMAC template is
> > enabled, it add 8 more bytes in descsize and reports warn_on because
> > descsize is 376 which is greater than 368 (HASH_MAX_DESCSIZE).
> >
> > HMAC versal-sha3-384 sha3-384-generic
> > 8 + 8 + 360 = 376
> >
> > What should be the preferred fix for this.
> > 1. Increase the size of HASH_MAX_DESCSIZE macro by 8.
> > 2. Register "versal-sha3-384" as ahash algo.
>
> There's no versal driver in the upstream kernel, so it's not entirely clear what
> you're talking about. But if you're just adding a new SHA-3 implementation it
> should use 'struct sha3_state' as the descriptor context, like the other ones.
> For HMAC that gives 8 + 360 = 368, i.e. HASH_MAX_DESCSIZE. The extra 8 bytes
> that you're somehow adding to get 8 + 8 + 360 should not be necessary.
Hi Eric,
Yes, Versal version not upstreamed yet.
Upstream driver's algo name is "zynqmp-sha3-384" in
drivers/crypto/xilinx/zynqmp-sha.c. We allocate fallback which adds 8
bytes and HMAC
too adds 8 byte.
Thanks.
>
> - Eric
