Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20201201142451.138221-1-giovanni.cabiddu@intel.com>
 <20201201142451.138221-3-giovanni.cabiddu@intel.com> <20201211100748.GA994@gondor.apana.org.au>
In-Reply-To: <20201211100748.GA994@gondor.apana.org.au>
From:   Ard Biesheuvel <ardb@kernel.org>
Date:   Fri, 11 Dec 2020 11:42:08 +0100
Message-ID: <CAMj1kXGr-aJ_uqoq+ooqp6iFSfGraQMHaGi8idd+qc_UXvp7FA@mail.gmail.com>
Subject: Re: [PATCH 2/3] crypto: qat - add AES-XTS support for QAT GEN4 devices
To:     Herbert Xu <herbert@gondor.apana.org.au>
Cc:     Giovanni Cabiddu <giovanni.cabiddu@intel.com>,
        Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
        qat-linux <qat-linux@intel.com>,
        Marco Chiappero <marco.chiappero@intel.com>,
        Tomaszx Kowalik <tomaszx.kowalik@intel.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Fri, 11 Dec 2020 at 11:07, Herbert Xu <herbert@gondor.apana.org.au> wrote:
>
> On Tue, Dec 01, 2020 at 02:24:50PM +0000, Giovanni Cabiddu wrote:
> >
> > @@ -1293,6 +1366,12 @@ static int qat_alg_skcipher_init_xts_tfm(struct crypto_skcipher *tfm)
> >       if (IS_ERR(ctx->ftfm))
> >               return PTR_ERR(ctx->ftfm);
> >
> > +     ctx->tweak = crypto_alloc_cipher("aes", 0, 0);
> > +     if (IS_ERR(ctx->tweak)) {
> > +             crypto_free_skcipher(ctx->ftfm);
> > +             return PTR_ERR(ctx->tweak);
> > +     }
> > +
> >       reqsize = max(sizeof(struct qat_crypto_request),
> >                     sizeof(struct skcipher_request) +
> >                     crypto_skcipher_reqsize(ctx->ftfm));
>
> This may clash with the work that Ard is doing on simpler ciphers.
>
> So I think this should switch over to using the library interface
> for aes.  What do you think Ard?
>

I think this is a valid use of a bare cipher - it lives as long as the
TFM itself, and may be used on a hot path.

I need to respin the bare cipher change I sent the other day anyway,
so I'll make sure this driver gets the right treatment as well (which
shouldn't cause any conflicts so the changes can be merged in any
order)