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
On Mon, Aug 05, 2013 at 05:25:57PM -0300, Marcelo Cerri wrote:
>
> 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
Yes.
> blkcipher the only implementation-specific context that can be used is
> allocated inside the tfm struct.
Both blkcipher and ablkcipher are meant to be fully reentrant.
So you must take necessary precautions if your implementation
is not reentrant, e.g., by locking.
> 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?
>From what you've said NFS seems to be doing the right thing, so the
bug would be in the driver.
> 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?
In general which model you pick for drivers depend on what your
hardware looks like. For example, padlock-aes uses the blkcipher
model because the hardware presents itself through a synchronous
CPU instruction, while most other drivers use the ablkcipher
interface because the underlying hardware completes asynchronously.
A blkcipher implementation is always available through both the
blkcipher and the ablkcipher interface. While an ablkcipher
implementaiton can only be used through the ablkcipher interface.
Cheers,
--
Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Hi Herbert,
Thanks for your answers.
On Tue, Aug 06, 2013 at 05:00:10PM +1000, Herbert Xu wrote:
> On Mon, Aug 05, 2013 at 05:25:57PM -0300, Marcelo Cerri wrote:
> >
> > 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
>
> Yes.
>
> > blkcipher the only implementation-specific context that can be used is
> > allocated inside the tfm struct.
>
> Both blkcipher and ablkcipher are meant to be fully reentrant.
> So you must take necessary precautions if your implementation
> is not reentrant, e.g., by locking.
I was considering a spin lock for that, since the cryptographic
functions can be called from a softirq context. However I don't consider
a lock a good solution because that could be done without any locks if
it was possible to keep the current state separated for each operation
in progress.
>
> > 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?
>
> From what you've said NFS seems to be doing the right thing, so the
> bug would be in the driver.
>
> > 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?
>
> In general which model you pick for drivers depend on what your
> hardware looks like. For example, padlock-aes uses the blkcipher
> model because the hardware presents itself through a synchronous
> CPU instruction, while most other drivers use the ablkcipher
> interface because the underlying hardware completes asynchronously.
>
> A blkcipher implementation is always available through both the
> blkcipher and the ablkcipher interface. While an ablkcipher
> implementaiton can only be used through the ablkcipher interface.
Now a lot of things start to make sense :P
So is that the reason because some drivers implement an ablkcipher and
then re-implements the same algorithm as a blkcipher just using a wrapper
over the asynchronous version?
I saw it's possible to keep a context in an ablkcipher_request
structure. I'm assuming that multiple callers using the same tfm still
would have to use different requests. So do you think that implementing
it as an asynchronous block cipher would be an alternative to locks in
the NX driver?
Regards,
Marcelo
Herbert,
Let me include a few more questions.
There are flags in several structures such as crypto_async_request,
blkcipher_desc and crypto_tfm. How they are intended to be used?
For example if I want to explicitly make a call that shouldn't sleep,
should I clear the CRYPTO_TFM_REQ_MAY_SLEEP in one of these structures?
And in which one?
Since cryptographic methods can be called in softirq contexts, is the
caller responsible for setting this flag correctly based on the context
it is running?
Regards,
Marcelo
On Tue, Aug 06, 2013 at 09:05:41AM -0300, Marcelo Cerri wrote:
> Hi Herbert,
>
> Thanks for your answers.
>
> On Tue, Aug 06, 2013 at 05:00:10PM +1000, Herbert Xu wrote:
> > On Mon, Aug 05, 2013 at 05:25:57PM -0300, Marcelo Cerri wrote:
> > >
> > > 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
> >
> > Yes.
> >
> > > blkcipher the only implementation-specific context that can be used is
> > > allocated inside the tfm struct.
> >
> > Both blkcipher and ablkcipher are meant to be fully reentrant.
> > So you must take necessary precautions if your implementation
> > is not reentrant, e.g., by locking.
>
> I was considering a spin lock for that, since the cryptographic
> functions can be called from a softirq context. However I don't consider
> a lock a good solution because that could be done without any locks if
> it was possible to keep the current state separated for each operation
> in progress.
>
> >
> > > 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?
> >
> > From what you've said NFS seems to be doing the right thing, so the
> > bug would be in the driver.
> >
> > > 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?
> >
> > In general which model you pick for drivers depend on what your
> > hardware looks like. For example, padlock-aes uses the blkcipher
> > model because the hardware presents itself through a synchronous
> > CPU instruction, while most other drivers use the ablkcipher
> > interface because the underlying hardware completes asynchronously.
> >
> > A blkcipher implementation is always available through both the
> > blkcipher and the ablkcipher interface. While an ablkcipher
> > implementaiton can only be used through the ablkcipher interface.
>
> Now a lot of things start to make sense :P
>
> So is that the reason because some drivers implement an ablkcipher and
> then re-implements the same algorithm as a blkcipher just using a wrapper
> over the asynchronous version?
>
> I saw it's possible to keep a context in an ablkcipher_request
> structure. I'm assuming that multiple callers using the same tfm still
> would have to use different requests. So do you think that implementing
> it as an asynchronous block cipher would be an alternative to locks in
> the NX driver?
>
> Regards,
> Marcelo
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
On Tue, Aug 06, 2013 at 11:16:12AM -0300, Marcelo Cerri wrote:
> Herbert,
>
> Let me include a few more questions.
>
> There are flags in several structures such as crypto_async_request,
> blkcipher_desc and crypto_tfm. How they are intended to be used?
>
> For example if I want to explicitly make a call that shouldn't sleep,
> should I clear the CRYPTO_TFM_REQ_MAY_SLEEP in one of these structures?
> And in which one?
>
> Since cryptographic methods can be called in softirq contexts, is the
> caller responsible for setting this flag correctly based on the context
> it is running?
Yes, although MAY_SLEEP is mostly used by synchronous implementations
since async drivers can simply return instead of sleeping.
Cheers,
--
Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
On Tue, Aug 06, 2013 at 09:05:41AM -0300, Marcelo Cerri wrote:
>
> I saw it's possible to keep a context in an ablkcipher_request
> structure. I'm assuming that multiple callers using the same tfm still
> would have to use different requests. So do you think that implementing
> it as an asynchronous block cipher would be an alternative to locks in
> the NX driver?
It really depends on your hardware. For example, does it provide
a convenient way of notifying the completion of an operation?
Cheers,
--
Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Thanks for Marcelo and Herbert for the questions and answers.
I have a few more questions related to the same subject of API.
1. In the crypto_async_request, is the list element available to the driver to use? I see most of drivers do "crypto_enqueue_request()" to keep track of the outstanding async requests. The only exception I have seen so far is talitos driver where they implement their FIFO to keep track the outstanding async requests.
2. The async driver simply returns instead of sleep. The requestor of the async request, does wait_for_completion() for the completion callback from driver. Can it be wait_for_completion_interruptible() such as testmgr.c does?
If the sleep can be interruptible, how does driver know the request has been aborted? The request can be still in the driver queue waiting for the hw to finish execution. How is driver aware to dequeue this aborted request? If not, the link list can be corrupted and cause kernel to crash potentially.
Chemin
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Herbert Xu
Sent: Thursday, August 08, 2013 1:02 AM
To: Marcelo Cerri
Cc: [email protected]
Subject: Re: Questions about the Crypto API
On Tue, Aug 06, 2013 at 11:16:12AM -0300, Marcelo Cerri wrote:
> Herbert,
>
> Let me include a few more questions.
>
> There are flags in several structures such as crypto_async_request,
> blkcipher_desc and crypto_tfm. How they are intended to be used?
>
> For example if I want to explicitly make a call that shouldn't sleep,
> should I clear the CRYPTO_TFM_REQ_MAY_SLEEP in one of these structures?
> And in which one?
>
> Since cryptographic methods can be called in softirq contexts, is the
> caller responsible for setting this flag correctly based on the
> context it is running?
Yes, although MAY_SLEEP is mostly used by synchronous implementations since async drivers can simply return instead of sleeping.
Cheers,
--
Email: Herbert Xu <[email protected]> Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Hi Herbert
> -----Original Message-----
> From: [email protected] [mailto:linux-crypto-
> [email protected]] On Behalf Of Herbert Xu
> Sent: Tuesday, August 06, 2013 12:30 PM
> To: Marcelo Cerri
> Cc: [email protected]
> Subject: Re: Questions about the Crypto API
>
> On Mon, Aug 05, 2013 at 05:25:57PM -0300, Marcelo Cerri wrote:
> >
> > 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
>
> Yes.
>
In this post, you mentioned that tfm is single threaded.
Am I misinterpreting your statement?
http://www.mail-archive.com/[email protected]/msg08689.html
> > blkcipher the only implementation-specific context that can be used is
> > allocated inside the tfm struct.
>
> Both blkcipher and ablkcipher are meant to be fully reentrant.
> So you must take necessary precautions if your implementation is not
> reentrant, e.g., by locking.
>
> > 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?
>
> From what you've said NFS seems to be doing the right thing, so the bug
> would be in the driver.
>
> > 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?
>
> In general which model you pick for drivers depend on what your hardware
> looks like. For example, padlock-aes uses the blkcipher model because
> the hardware presents itself through a synchronous CPU instruction, while
> most other drivers use the ablkcipher interface because the underlying
> hardware completes asynchronously.
>
> A blkcipher implementation is always available through both the blkcipher
> and the ablkcipher interface. While an ablkcipher implementaiton can
> only be used through the ablkcipher interface.
>
> Cheers,
> --
> Email: Herbert Xu <[email protected]> Home Page:
> http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
> --
> To unsubscribe from this list: send the line "unsubscribe linux-crypto"
> in the body of a message to [email protected] More majordomo info
> at http://vger.kernel.org/majordomo-info.html
On Thu, Aug 08, 2013 at 02:50:41PM +0000, Garg Vakul-B16394 wrote:
> Hi Herbert
>
>
> > -----Original Message-----
> > From: [email protected] [mailto:linux-crypto-
> > [email protected]] On Behalf Of Herbert Xu
> > Sent: Tuesday, August 06, 2013 12:30 PM
> > To: Marcelo Cerri
> > Cc: [email protected]
> > Subject: Re: Questions about the Crypto API
> >
> > On Mon, Aug 05, 2013 at 05:25:57PM -0300, Marcelo Cerri wrote:
> > >
> > > 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
> >
> > Yes.
> >
>
> In this post, you mentioned that tfm is single threaded.
> Am I misinterpreting your statement?
>
> http://www.mail-archive.com/[email protected]/msg08689.html
>
Hi Herbert,
I also would like to better understand that. It doesn't seem natural for
me that a single tfm can be used by multiple kernel threads.
Best regards,
Marcelo
On Fri, Aug 09, 2013 at 01:09:12PM +0000, Hsieh, Che-Min wrote:
> Marcelo/Herbert:
>
> I believe It is. Herbert, please correct me if I am wrong.
> A single tfm is used as a user context to crypto, so to speak. But a user is not a thread.
> Let us use ipsec as example.
> For each security association (SA), it will take up a tfm.
> Assume I have IP sec setup between my local host and remote host. I might have two SA's, one for each direction.
> Now, I might run ping. Simultaneously, I might run iperf. I might run a lot of different things between these two ip hosts.
> But only two tfm's are involved.
> I have seen this happening in our system with ipsec setup as described above.
> While an async request is outstanding in the driver, another request is issued to the same driver for the same tfm.
Yes you're absolutely right.
Unless I've misunderstood Marcelo's question is different from
what Garg was asking.
Marcelo: The tfm, be it blkcipher or ablkcipher can always be used
in parallel by the user on different CPUs. For example, IPsec may
receive two packets on two CPUs through the same SA, in which case
decryption will be carried out in parallel.
Garg: For any tfm, blkcipher or ablkcipher, they must return results
in the order they were given. For a blkcipher which is synchronous,
this is always true by definition since we return only after the
result has been completed. For an async ablkcipher, this means that
if you receive two requests on the same CPU, then the first request
must be served and completed before the second request's completion
can be initiated.
Sorry for any confusion this might have caused.
Cheers,
--
Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
On Thu, Aug 08, 2013 at 02:04:05PM +0000, Hsieh, Che-Min wrote:
> Thanks for Marcelo and Herbert for the questions and answers.
> I have a few more questions related to the same subject of API.
>
> 1. In the crypto_async_request, is the list element available to the driver to use? I see most of drivers do "crypto_enqueue_request()" to keep track of the outstanding async requests. The only exception I have seen so far is talitos driver where they implement their FIFO to keep track the outstanding async requests.
You should use your own list element since this may interfere
with the crypto API's own queueing mechanism, if any (meaning
that even if in your particular case this field is unused by
the time you see it this may change in future).
> 2. The async driver simply returns instead of sleep. The requestor of the async request, does wait_for_completion() for the completion callback from driver. Can it be wait_for_completion_interruptible() such as testmgr.c does?
> If the sleep can be interruptible, how does driver know the request has been aborted? The request can be still in the driver queue waiting for the hw to finish execution. How is driver aware to dequeue this aborted request? If not, the link list can be corrupted and cause kernel to crash potentially.
If the requester is using the async interface then in general
the requester should not be sitting around waiting for it to
complete. See for example how we handle this in IPsec.
As for an aborted wait, the user must guarantee that any memory
associated with the request is not freed until the driver has
called the completion function. IOW we don't currently provide
a kill mechanism to the user.
Do you have a particular case where a kill mechanism would be
useful (memory corruption caused by the user freeing the request
early is just a bug)?
Cheers,
--
Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Thanks for Herbert response to my burning questions. Please see my follow on comments. Please correct me if my comments are not correct.
>> You should use your own list element
This is the conclusion I reached when I looked into our problem. I looked at other drivers and tailtos driver. I believe the only correct implementation is to use our own list, similar way as tailtos driver. Thanks for your confirmation.
Our problem is like the following. In our current implementation, we follow most of other drivers, (or we were lazy like rest of people, and just took easy way out :-)). We use the async request list structure, and API to maintain the outstanding requests.
We also develop a set of loadable modules, as test vehicle to test our driver. Our test module modeling after tcrypt, and testmgr, it is sitting in a loop, issuing various async request, and then wait_for_completion_interruptable().
So after issuing modprobe test_module to start a test, if I hit control C, kernel panic left to right, complaining about list broken....
>> As for an aborted wait, the user must guarantee that any memory
>> associated with the request is not freed until the driver has called the >> completion function. IOW we don't currently provide a kill mechanism >> to the user.
So the correct behavior, is, driver should not be aware of the aborted request above. It should always do completion callback. That means, after it accepts an async request (return with -EINPROGRESS), the request and the resource are guaranteed to the driver until driver finishes the requests, and do the completion callback. It is the requestor's responsibility to ensure this happening.
>> See for example how we handle this in IPsec.
Can you point to me a list of kernel module names that handle this. I can easily look into it for reference.
>> . IOW we don't currently provide a kill mechanism to the user.
Good. Tcrypt.c and Testmgr is only a bad example?
>> Do you have a particular case where a kill mechanism would be useful >> (memory corruption caused by the user freeing the request early is just >>a bug)?
I don't see a need of it. As long as the responsibility of each is well understood and observed. The crypto api to the driver is like a disk i/o request from above to a disk driver. To the driver, once it is requested, it should run to its completion. However, the driver implementation should always include a timeout function to make sure HW function properly. There is no hanging somewhere. I don't see too many people doing that (including us).
Cheers,
Chemin
-----Original Message-----
From: Herbert Xu [mailto:[email protected]]
Sent: Friday, August 09, 2013 9:21 PM
To: Hsieh, Che-Min
Cc: Marcelo Cerri; [email protected]
Subject: Re: Questions about the Crypto API
On Thu, Aug 08, 2013 at 02:04:05PM +0000, Hsieh, Che-Min wrote:
> Thanks for Marcelo and Herbert for the questions and answers.
> I have a few more questions related to the same subject of API.
>
> 1. In the crypto_async_request, is the list element available to the driver to use? I see most of drivers do "crypto_enqueue_request()" to keep track of the outstanding async requests. The only exception I have seen so far is talitos driver where they implement their FIFO to keep track the outstanding async requests.
You should use your own list element since this may interfere with the crypto API's own queueing mechanism, if any (meaning that even if in your particular case this field is unused by the time you see it this may change in future).
> 2. The async driver simply returns instead of sleep. The requestor of the async request, does wait_for_completion() for the completion callback from driver. Can it be wait_for_completion_interruptible() such as testmgr.c does?
> If the sleep can be interruptible, how does driver know the request has been aborted? The request can be still in the driver queue waiting for the hw to finish execution. How is driver aware to dequeue this aborted request? If not, the link list can be corrupted and cause kernel to crash potentially.
If the requester is using the async interface then in general the requester should not be sitting around waiting for it to complete. See for example how we handle this in IPsec.
As for an aborted wait, the user must guarantee that any memory associated with the request is not freed until the driver has called the completion function. IOW we don't currently provide a kill mechanism to the user.
Do you have a particular case where a kill mechanism would be useful (memory corruption caused by the user freeing the request early is just a bug)?
Cheers,
--
Email: Herbert Xu <[email protected]> Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
On Sat, Aug 10, 2013 at 02:15:10AM +0000, Hsieh, Che-Min wrote:
>
> >> . IOW we don't currently provide a kill mechanism to the user.
>
> Good. Tcrypt.c and Testmgr is only a bad example?
Right, they can't really do anything other than waiting so they're
not a realistic example.
For a good example, check out the IPsec implementation in
net/ipv4/esp4.c.
Cheers,
--
Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
On Sat, Aug 10, 2013 at 11:15:41AM +1000, Herbert Xu wrote:
> On Fri, Aug 09, 2013 at 01:09:12PM +0000, Hsieh, Che-Min wrote:
> > Marcelo/Herbert:
> >
> > I believe It is. Herbert, please correct me if I am wrong.
> > A single tfm is used as a user context to crypto, so to speak. But a user is not a thread.
> > Let us use ipsec as example.
> > For each security association (SA), it will take up a tfm.
> > Assume I have IP sec setup between my local host and remote host. I might have two SA's, one for each direction.
> > Now, I might run ping. Simultaneously, I might run iperf. I might run a lot of different things between these two ip hosts.
> > But only two tfm's are involved.
> > I have seen this happening in our system with ipsec setup as described above.
> > While an async request is outstanding in the driver, another request is issued to the same driver for the same tfm.
>
> Yes you're absolutely right.
>
> Unless I've misunderstood Marcelo's question is different from
> what Garg was asking.
>
> Marcelo: The tfm, be it blkcipher or ablkcipher can always be used
> in parallel by the user on different CPUs. For example, IPsec may
> receive two packets on two CPUs through the same SA, in which case
> decryption will be carried out in parallel.
So does that means that it's possible to keep data in the tfm's context
that is the same for a single SA, such as the AES expanded key, but it's
not possible to keep data that is specific for the current operation,
such as an operation state that the driver might require?
Actually I think that probably I have misunderstood the blkcipher
interface, so here it is another question: is each encrypt/decrypt call
a complete operation? I mean, I'm considering that I could always chain
a series of calls to encrypt data in separated chunks, in a similar way
that is done for the hash interface and because that I'm assuming that I
would have to keep state between those calls if the device requires
that.
>
> Garg: For any tfm, blkcipher or ablkcipher, they must return results
> in the order they were given. For a blkcipher which is synchronous,
> this is always true by definition since we return only after the
> result has been completed. For an async ablkcipher, this means that
> if you receive two requests on the same CPU, then the first request
> must be served and completed before the second request's completion
> can be initiated.
>
> Sorry for any confusion this might have caused.
>
> Cheers,
> --
> Email: Herbert Xu <[email protected]>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
> --
> To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> Garg: For any tfm, blkcipher or ablkcipher, they must return results
> in the order they were given. For a blkcipher which is synchronous,
> this is always true by definition since we return only after the
> result has been completed. For an async ablkcipher, this means that
> if you receive two requests on the same CPU, then the first request
> must be served and completed before the second request's completion
> can be initiated.
Herbert, can you give further clarification:
(*) This ordering of result is also true for others, such as aead and hashing, right?
Can you confirm, or correct the following statements:
(*)To perform hashing on a long data stream, it may come in multiple requests to the driver; in a sequence of one .init request, one or more than one .update requests, and lastly one .final request. In this sequence, a request has to be complete, before next one to be issued to the driver. Those requests should always come in the same struct crypto_async_request.
Is this correct?
If driver needs to maintain state variables for such (init, update, final), the state variables can be maintained in the request implementation context, instead of tfm context. Right?
Thanks.
Chemin
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Marcelo Cerri
Sent: Monday, August 12, 2013 9:49 AM
To: Herbert Xu
Cc: Hsieh, Che-Min; Garg Vakul-B16394; [email protected]
Subject: Re: Questions about the Crypto API
On Sat, Aug 10, 2013 at 11:15:41AM +1000, Herbert Xu wrote:
> On Fri, Aug 09, 2013 at 01:09:12PM +0000, Hsieh, Che-Min wrote:
> > Marcelo/Herbert:
> >
> > I believe It is. Herbert, please correct me if I am wrong.
> > A single tfm is used as a user context to crypto, so to speak. But a user is not a thread.
> > Let us use ipsec as example.
> > For each security association (SA), it will take up a tfm.
> > Assume I have IP sec setup between my local host and remote host. I might have two SA's, one for each direction.
> > Now, I might run ping. Simultaneously, I might run iperf. I might run a lot of different things between these two ip hosts.
> > But only two tfm's are involved.
> > I have seen this happening in our system with ipsec setup as described above.
> > While an async request is outstanding in the driver, another request is issued to the same driver for the same tfm.
>
> Yes you're absolutely right.
>
> Unless I've misunderstood Marcelo's question is different from what
> Garg was asking.
>
> Marcelo: The tfm, be it blkcipher or ablkcipher can always be used in
> parallel by the user on different CPUs. For example, IPsec may
> receive two packets on two CPUs through the same SA, in which case
> decryption will be carried out in parallel.
So does that means that it's possible to keep data in the tfm's context that is the same for a single SA, such as the AES expanded key, but it's not possible to keep data that is specific for the current operation, such as an operation state that the driver might require?
Actually I think that probably I have misunderstood the blkcipher interface, so here it is another question: is each encrypt/decrypt call a complete operation? I mean, I'm considering that I could always chain a series of calls to encrypt data in separated chunks, in a similar way that is done for the hash interface and because that I'm assuming that I would have to keep state between those calls if the device requires that.
>
> Garg: For any tfm, blkcipher or ablkcipher, they must return results
> in the order they were given. For a blkcipher which is synchronous,
> this is always true by definition since we return only after the
> result has been completed. For an async ablkcipher, this means that
> if you receive two requests on the same CPU, then the first request
> must be served and completed before the second request's completion
> can be initiated.
>
> Sorry for any confusion this might have caused.
>
> Cheers,
> --
> Email: Herbert Xu <[email protected]> Home Page:
> http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-crypto" in the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
On Mon, Aug 12, 2013 at 10:49:13AM -0300, Marcelo Cerri wrote:
>
> So does that means that it's possible to keep data in the tfm's context
> that is the same for a single SA, such as the AES expanded key, but it's
> not possible to keep data that is specific for the current operation,
> such as an operation state that the driver might require?
Correct.
> Actually I think that probably I have misunderstood the blkcipher
> interface, so here it is another question: is each encrypt/decrypt call
> a complete operation? I mean, I'm considering that I could always chain
> a series of calls to encrypt data in separated chunks, in a similar way
> that is done for the hash interface and because that I'm assuming that I
> would have to keep state between those calls if the device requires
> that.
You could always chain blkcipher operations together, however, the
only state that can be stored is the IV.
Cheers,
--
Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
On Tue, Aug 13, 2013 at 07:25:50PM +0000, Hsieh, Che-Min wrote:
> > Garg: For any tfm, blkcipher or ablkcipher, they must return results
> > in the order they were given. For a blkcipher which is synchronous,
> > this is always true by definition since we return only after the
> > result has been completed. For an async ablkcipher, this means that
> > if you receive two requests on the same CPU, then the first request
> > must be served and completed before the second request's completion
> > can be initiated.
>
> Herbert, can you give further clarification:
> (*) This ordering of result is also true for others, such as aead and hashing, right?
Correct.
> Can you confirm, or correct the following statements:
> (*)To perform hashing on a long data stream, it may come in multiple requests to the driver; in a sequence of one .init request, one or more than one .update requests, and lastly one .final request. In this sequence, a request has to be complete, before next one to be issued to the driver. Those requests should always come in the same struct crypto_async_request.
> Is this correct?
No. Operations can always be interleaved, i.e., two different
requests can both start with init and then update in lock-step.
For hashes all state must be confined to the context area of
ahash_request. That is, the hardware must not maintain internal
state, or if it does, it must be prepared to refresh its state if
an ahash_request comes in that does not agree with the hardware's
current state.
Now, I understand that not all hardware makes it easy to do this,
that is why we don't require all hardware to provide the
init/update/final interface. The hardware can provide only the
digest interface (and most likely the finup interface) and then
rely on a software fall-back for the "stateless" init/update/final
operations.
Accordingly, on the user side we encourage everyone to use digest
and/or finup wherever possible so that the chances of hardware
acceleration is maximised.
> If driver needs to maintain state variables for such (init, update, final), the state variables can be maintained in the request implementation context, instead of tfm context. Right?
Right.
Cheers,
--
Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt