From: Marcelo Cerri <mhcerri@linux.vnet.ibm.com>
To: linux-crypto@vger.kernel.org, herbert@gondor.apana.org.au
Subject: Questions about the Crypto API
Date: Mon, 5 Aug 2013 17:25:57 -0300 [thread overview]
Message-ID: <20130805202557.GE5752@oc8526070481.ibm.com> (raw)
Hi,
I'm starting to work on some platform-specific implementations using the
Crypto API. I spent some time reading the available documentation and
mainly the code, but I still have some doubts on how the Crypto API
works and how it should be used.
My first doubt is regarding which kind of concurrency the Crypto API
allows. For example, can a single `struct crypto_tfm` be used by two
concurrent calls? I'm asking about that because I noticed that for
blkcipher the only implementation-specific context that can be used is
allocated inside the tfm struct.
I'm working to fix some bugs in the NX driver (located in
drivers/crypto/nx), and one issue that we are facing is that NFS when
using Kerberos uses the same tfm with different kthreads. That causes
concurrent accesses to the internal data stored into the context and
incorrect results.
So my question here is: should this type of concurrency be handled by
the driver or a caller is not allowed to use the same tfm for concurrent
calls?
My second doubt is regarding the difference between ablkcipher and
blkcipher. I do understand their difference from caller's point of view.
But I'm not sure what are the consequences of implementing a driver
using one or another option.
For example, can a blkcipher implementation be used asynchronously and
vice versa?
Thanks for your help.
Marcelo
next reply other threads:[~2013-08-05 20:26 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-05 20:25 Marcelo Cerri [this message]
2013-08-06 7:00 ` Questions about the Crypto API Herbert Xu
2013-08-06 12:05 ` Marcelo Cerri
2013-08-06 14:16 ` Marcelo Cerri
2013-08-08 5:01 ` Herbert Xu
2013-08-08 14:04 ` Hsieh, Che-Min
2013-08-10 1:21 ` Herbert Xu
2013-08-10 2:15 ` Hsieh, Che-Min
2013-08-10 6:17 ` Herbert Xu
2013-08-08 5:02 ` Herbert Xu
2013-08-08 14:50 ` Garg Vakul-B16394
2013-08-09 12:55 ` Marcelo Cerri
[not found] ` <A83C99F8370D4D42BEB2D2B3153A6BBC23D55A6E@NASANEXD02C.na.qualcomm.com>
2013-08-10 1:15 ` Herbert Xu
2013-08-12 13:49 ` Marcelo Cerri
2013-08-13 19:25 ` Hsieh, Che-Min
2013-08-16 6:37 ` Herbert Xu
2013-08-16 6:30 ` Herbert Xu
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=20130805202557.GE5752@oc8526070481.ibm.com \
--to=mhcerri@linux.vnet.ibm.com \
--cc=herbert@gondor.apana.org.au \
--cc=linux-crypto@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox