From: Corentin Labbe <clabbe.montjoie@gmail.com>
To: Fabien DESSENNE <fabien.dessenne@st.com>
Cc: Alexandre TORGUE <alexandre.torgue@st.com>,
"arei.gonglei@huawei.com" <arei.gonglei@huawei.com>,
"corbet@lwn.net" <corbet@lwn.net>,
"davem@davemloft.net" <davem@davemloft.net>,
"herbert@gondor.apana.org.au" <herbert@gondor.apana.org.au>,
"jasowang@redhat.com" <jasowang@redhat.com>,
"mcoquelin.stm32@gmail.com" <mcoquelin.stm32@gmail.com>,
"mst@redhat.com" <mst@redhat.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"virtualization@lists.linux-foundation.org"
<virtualization@lists.linux-foundation.org>,
Benjamin GAIGNARD <benjamin.gaignard@st.com>
Subject: Re: [PATCH 1/6] Documentation: crypto: document crypto engine API
Date: Wed, 10 Jan 2018 20:14:50 +0100 [thread overview]
Message-ID: <20180110191450.GB12214@Red> (raw)
In-Reply-To: <849600f6-3082-c090-205d-75e3d14b38f9@st.com>
On Wed, Jan 10, 2018 at 02:13:13PM +0000, Fabien DESSENNE wrote:
> Hi Corentin,
>
>
> Thank you for this new version which I have testes successfully with the
> stm32 hash & cryp drivers.
>
> As a general comment on this patchset, I would say that it does not
> cover all async requests: typically I need (for the pending stm32 cryp
> driver uprade) to use CryptoEngine to process AEAD requests which is not
> covered here.
>
> Could you please consider adding the 'transfer' and 'finalize' EXPORTed
> functions for aead requests? (the implementation is quite trivial)
>
> Have also a look at struct acomp_req (acompress.h) and struct
> kpp_request (kpp.h) which also use "struct crypto_async_request base"
>
>
> BR
>
> Fabien
>
Hello
Thanks for your review and test (could I add your tested-by ?).
I didn't add aead (and kpp/acompress), since I do not have any way to test it.
Since you have a way to test aead, I will add it to the next release.
Regards
>
> On 03/01/18 21:11, Corentin Labbe wrote:
> > Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
> > ---
> > Documentation/crypto/crypto_engine.rst | 46 ++++++++++++++++++++++++++++++++++
> > 1 file changed, 46 insertions(+)
> > create mode 100644 Documentation/crypto/crypto_engine.rst
> >
> > diff --git a/Documentation/crypto/crypto_engine.rst b/Documentation/crypto/crypto_engine.rst
> > new file mode 100644
> > index 000000000000..b0ed37f9fb0c
> > --- /dev/null
> > +++ b/Documentation/crypto/crypto_engine.rst
> > @@ -0,0 +1,46 @@
> > +=============
> > +CRYPTO ENGINE
> > +=============
> > +
> > +Overview
> > +--------
> > +The crypto engine API (CE), is a crypto queue manager.
> > +
> > +Requirement
> > +-----------
> > +You have to put at start of your tfm_ctx the struct crypto_engine_reqctx
> > +struct your_tfm_ctx {
> > + struct crypto_engine_reqctx enginectx;
> > + ...
> > +};
> > +Why: Since CE manage only crypto_async_request, it cannot know the underlying
> > +request_type and so have access only on the TFM.
> > +So using container_of for accessing __ctx is impossible.
> > +Furthermore, the crypto engine cannot know the "struct your_tfm_ctx",
> > +so it must assume that crypto_engine_reqctx is at start of it.
> > +
> > +Order of operations
> > +-------------------
> > +You have to obtain a struct crypto_engine via crypto_engine_alloc_init().
> > +And start it via crypto_engine_start().
> > +
> > +Before transferring any request, you have to fill the enginectx.
> > +- prepare_request: (taking a function pointer) If you need to do some processing before doing the request
> > +- unprepare_request: (taking a function pointer) Undoing what's done in prepare_request
> > +- do_one_request: (taking a function pointer) Do encryption for current request
> > +
> > +Note: that those three functions get the crypto_async_request associated with the received request.
> > +So your need to get the original request via container_of(areq, struct yourrequesttype_request, base);
> > +
> > +When your driver receive a crypto_request, you have to transfer it to
> > +the cryptoengine via one of:
> > +- crypto_transfer_cipher_request_to_engine()
> > +- crypto_transfer_skcipher_request_to_engine()
> > +- crypto_transfer_akcipher_request_to_engine()
> > +- crypto_transfer_hash_request_to_engine()
> > +
> > +At the end of the request process, a call to one of the following function is needed:
> > +- crypto_finalize_cipher_request
> > +- crypto_finalize_skcipher_request
> > +- crypto_finalize_akcipher_request
> > +- crypto_finalize_hash_request
WARNING: multiple messages have this Message-ID (diff)
From: clabbe.montjoie@gmail.com (Corentin Labbe)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/6] Documentation: crypto: document crypto engine API
Date: Wed, 10 Jan 2018 20:14:50 +0100 [thread overview]
Message-ID: <20180110191450.GB12214@Red> (raw)
In-Reply-To: <849600f6-3082-c090-205d-75e3d14b38f9@st.com>
On Wed, Jan 10, 2018 at 02:13:13PM +0000, Fabien DESSENNE wrote:
> Hi Corentin,
>
>
> Thank you for this new version which I have testes successfully with the
> stm32 hash & cryp drivers.
>
> As a general comment on this patchset, I would say that it does not
> cover all async requests: typically I need (for the pending stm32 cryp
> driver uprade) to use CryptoEngine to process AEAD requests which is not
> covered here.
>
> Could you please consider adding the 'transfer' and 'finalize' EXPORTed
> functions for aead requests? (the implementation is quite trivial)
>
> Have also a look at struct acomp_req (acompress.h) and struct
> kpp_request (kpp.h) which also use "struct crypto_async_request base"
>
>
> BR
>
> Fabien
>
Hello
Thanks for your review and test (could I add your tested-by ?).
I didn't add aead (and kpp/acompress), since I do not have any way to test it.
Since you have a way to test aead, I will add it to the next release.
Regards
>
> On 03/01/18 21:11, Corentin Labbe wrote:
> > Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
> > ---
> > Documentation/crypto/crypto_engine.rst | 46 ++++++++++++++++++++++++++++++++++
> > 1 file changed, 46 insertions(+)
> > create mode 100644 Documentation/crypto/crypto_engine.rst
> >
> > diff --git a/Documentation/crypto/crypto_engine.rst b/Documentation/crypto/crypto_engine.rst
> > new file mode 100644
> > index 000000000000..b0ed37f9fb0c
> > --- /dev/null
> > +++ b/Documentation/crypto/crypto_engine.rst
> > @@ -0,0 +1,46 @@
> > +=============
> > +CRYPTO ENGINE
> > +=============
> > +
> > +Overview
> > +--------
> > +The crypto engine API (CE), is a crypto queue manager.
> > +
> > +Requirement
> > +-----------
> > +You have to put at start of your tfm_ctx the struct crypto_engine_reqctx
> > +struct your_tfm_ctx {
> > + struct crypto_engine_reqctx enginectx;
> > + ...
> > +};
> > +Why: Since CE manage only crypto_async_request, it cannot know the underlying
> > +request_type and so have access only on the TFM.
> > +So using container_of for accessing __ctx is impossible.
> > +Furthermore, the crypto engine cannot know the "struct your_tfm_ctx",
> > +so it must assume that crypto_engine_reqctx is at start of it.
> > +
> > +Order of operations
> > +-------------------
> > +You have to obtain a struct crypto_engine via crypto_engine_alloc_init().
> > +And start it via crypto_engine_start().
> > +
> > +Before transferring any request, you have to fill the enginectx.
> > +- prepare_request: (taking a function pointer) If you need to do some processing before doing the request
> > +- unprepare_request: (taking a function pointer) Undoing what's done in prepare_request
> > +- do_one_request: (taking a function pointer) Do encryption for current request
> > +
> > +Note: that those three functions get the crypto_async_request associated with the received request.
> > +So your need to get the original request via container_of(areq, struct yourrequesttype_request, base);
> > +
> > +When your driver receive a crypto_request, you have to transfer it to
> > +the cryptoengine via one of:
> > +- crypto_transfer_cipher_request_to_engine()
> > +- crypto_transfer_skcipher_request_to_engine()
> > +- crypto_transfer_akcipher_request_to_engine()
> > +- crypto_transfer_hash_request_to_engine()
> > +
> > +At the end of the request process, a call to one of the following function is needed:
> > +- crypto_finalize_cipher_request
> > +- crypto_finalize_skcipher_request
> > +- crypto_finalize_akcipher_request
> > +- crypto_finalize_hash_request
next prev parent reply other threads:[~2018-01-10 19:14 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-03 20:11 [PATCH 0/6] crypto: engine - Permit to enqueue all async requests Corentin Labbe
2018-01-03 20:11 ` Corentin Labbe
2018-01-03 20:11 ` Corentin Labbe
2018-01-03 20:11 ` [PATCH 1/6] Documentation: crypto: document crypto engine API Corentin Labbe
2018-01-03 20:11 ` Corentin Labbe
2018-01-03 20:11 ` Corentin Labbe
2018-01-10 14:13 ` Fabien DESSENNE
2018-01-10 14:13 ` Fabien DESSENNE
2018-01-10 14:13 ` Fabien DESSENNE
2018-01-10 19:14 ` Corentin Labbe [this message]
2018-01-10 19:14 ` Corentin Labbe
2018-01-10 19:14 ` Corentin Labbe
2018-01-03 20:11 ` [PATCH 2/6] crypto: engine - Permit to enqueue all async requests Corentin Labbe
2018-01-03 20:11 ` Corentin Labbe
2018-01-03 20:11 ` Corentin Labbe
2018-01-10 14:19 ` Fabien DESSENNE
2018-01-10 14:19 ` Fabien DESSENNE
2018-01-10 14:19 ` Fabien DESSENNE
2018-01-10 14:19 ` Fabien DESSENNE
2018-01-11 7:44 ` Fabien DESSENNE
2018-01-11 7:44 ` Fabien DESSENNE
2018-01-11 7:44 ` Fabien DESSENNE
2018-01-11 7:44 ` Fabien DESSENNE
2018-01-12 7:14 ` Herbert Xu
2018-01-12 7:14 ` Herbert Xu
2018-01-12 7:14 ` Herbert Xu
2018-01-03 20:11 ` [PATCH 3/6] crypto: omap: convert to new crypto engine API Corentin Labbe
2018-01-03 20:11 ` Corentin Labbe
2018-01-03 20:11 ` Corentin Labbe
2018-01-03 20:11 ` [PATCH 4/6] crypto: virtio: " Corentin Labbe
2018-01-03 20:11 ` Corentin Labbe
2018-01-03 20:11 ` Corentin Labbe
2018-01-03 20:11 ` [PATCH 5/6] crypto: stm32-hash: convert to the " Corentin Labbe
2018-01-03 20:11 ` Corentin Labbe
2018-01-03 20:11 ` Corentin Labbe
2018-01-10 14:24 ` Fabien DESSENNE
2018-01-10 14:24 ` Fabien DESSENNE
2018-01-10 14:24 ` Fabien DESSENNE
2018-01-10 14:24 ` Fabien DESSENNE
2018-01-11 7:44 ` Fabien DESSENNE
2018-01-11 7:44 ` Fabien DESSENNE
2018-01-11 7:44 ` Fabien DESSENNE
2018-01-11 7:44 ` Fabien DESSENNE
2018-01-03 20:11 ` [PATCH 6/6] crypto: stm32-cryp: " Corentin Labbe
2018-01-03 20:11 ` Corentin Labbe
2018-01-03 20:11 ` Corentin Labbe
2018-01-10 14:25 ` Fabien DESSENNE
2018-01-10 14:25 ` Fabien DESSENNE
2018-01-10 14:25 ` Fabien DESSENNE
2018-01-11 7:45 ` Fabien DESSENNE
2018-01-11 7:45 ` Fabien DESSENNE
2018-01-11 7:45 ` Fabien DESSENNE
2018-01-10 14:25 ` Fabien DESSENNE
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=20180110191450.GB12214@Red \
--to=clabbe.montjoie@gmail.com \
--cc=alexandre.torgue@st.com \
--cc=arei.gonglei@huawei.com \
--cc=benjamin.gaignard@st.com \
--cc=corbet@lwn.net \
--cc=davem@davemloft.net \
--cc=fabien.dessenne@st.com \
--cc=herbert@gondor.apana.org.au \
--cc=jasowang@redhat.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mcoquelin.stm32@gmail.com \
--cc=mst@redhat.com \
--cc=virtualization@lists.linux-foundation.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.