Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <DM6PR19MB31633BFB6AD885E0EAF68F14A1419@DM6PR19MB3163.namprd19.prod.outlook.com>
References: <de6de430fd9bbc2d38ff2d5a1ce89983421b9dda.1662432407.git.pliem@maxlinear.com> <60cb9b954bb079b1f12379821a64faff00bb368e.1662432407.git.pliem@maxlinear.com> <166247313358.3585.5988889047992659412@kwain> <DM6PR19MB31633BFB6AD885E0EAF68F14A1419@DM6PR19MB3163.namprd19.prod.outlook.com>
From:   Antoine Tenart <atenart@kernel.org>
Subject: Re: [PATCH v2 2/2] crypto: inside-secure - Select CRYPTO_AES config
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>
Message-ID: <166254049905.4625.8082287890585826042@kwain>
Date:   Wed, 07 Sep 2022 10:48:19 +0200
Precedence: bulk

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")
> >=20
> > 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?
>=20
> 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