Linux cryptographic layer development
 help / color / mirror / Atom feed
From: Antoine Tenart <atenart@kernel.org>
To: "herbert@gondor.apana.org.au" <herbert@gondor.apana.org.au>,
	Peter Harliman Liem <pliem@maxlinear.com>
Cc: "linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
	linux-lgm-soc <linux-lgm-soc@maxlinear.com>
Subject: Re: [PATCH v2 2/2] crypto: inside-secure - Select CRYPTO_AES config
Date: Wed, 07 Sep 2022 10:48:19 +0200	[thread overview]
Message-ID: <166254049905.4625.8082287890585826042@kwain> (raw)
In-Reply-To: <DM6PR19MB31633BFB6AD885E0EAF68F14A1419@DM6PR19MB3163.namprd19.prod.outlook.com>

Quoting Peter Harliman Liem (2022-09-07 08:46:32)
> On 6/9/2022 10:05 pm, Antoine Tenart wrote:
> >> CRYPTO_AES is needed for aes-related algo (e.g.
> >> safexcel-gcm-aes, safexcel-xcbc-aes, safexcel-cmac-aes).
> >> Without it, we observe failures when allocating transform
> >> for those algo.
> >>
> >> Fixes: 363a90c2d517 ("crypto: safexcel/aes - switch to library version of key expansion routine")
> > 
> > The above commit explicitly switched crypto drivers to use the AES
> > library instead of the generic AES cipher one, which seems like a good
> > move. What are the issues you're encountering and why the AES lib makes
> > the driver to fail?
> 
> If I load the kernel module (CONFIG_CRYPTO_MANAGER_DISABLE_TESTS is not
> set), I am getting failure messages below.
> IMHO this happens because some functions in the driver still rely on
> generic AES cipher (e.g. refer to safexcel_aead_gcm_cra_init() or
> safexcel_xcbcmac_cra_init()), therefore CONFIG_CRYPTO_AES is still needed.

That's possible, and the right fix might be what you proposed. I think
it would be nice to understand what is failing and where, so we have a
good argument for restoring the AES dependency (or not).

> Maybe the alternative is to switch all of them to use AES lib instead?
> Let me know if you prefer this.

If the AES lib can be used instead of the AES generic implementation
that would be great yes. If that's possible, depending on what is
actually failing, yes please go for this solution. Otherwise restoring
the AES dependency with a good explanation should work.

Thanks!
Antoine

  reply	other threads:[~2022-09-07  8:48 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-06  2:51 [PATCH v2 1/2] crypto: inside_secure - Avoid dma map if size is zero Peter Harliman Liem
2022-09-06  2:51 ` [PATCH v2 2/2] crypto: inside-secure - Select CRYPTO_AES config Peter Harliman Liem
2022-09-06 14:05   ` Antoine Tenart
2022-09-07  6:46     ` Peter Harliman Liem
2022-09-07  8:48       ` Antoine Tenart [this message]
2022-09-23  2:39         ` Peter Harliman Liem
2022-09-06 14:00 ` [PATCH v2 1/2] crypto: inside_secure - Avoid dma map if size is zero Antoine Tenart
2022-09-07  6:43   ` Peter Harliman Liem
2022-09-07  6:52 ` Herbert Xu
2022-09-23  2:35   ` Peter Harliman Liem

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=166254049905.4625.8082287890585826042@kwain \
    --to=atenart@kernel.org \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-lgm-soc@maxlinear.com \
    --cc=pliem@maxlinear.com \
    /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