RE: Questions about the Crypto API
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: linux-crypto-ow...@vger.kernel.org [mailto:linux-crypto-ow...@vger.kernel.org] On Behalf Of Marcelo Cerri Sent: Monday, August 12, 2013 9:49 AM To: Herbert Xu Cc: Hsieh, Che-Min; Garg Vakul-B16394; linux-crypto@vger.kernel.org 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 +, 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 herb...@gondor.apana.org.au 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 +, 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 herb...@gondor.apana.org.au 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Questions about the Crypto API
On Sat, Aug 10, 2013 at 02:15:10AM +, 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 herb...@gondor.apana.org.au 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Questions about the Crypto API
On Fri, Aug 09, 2013 at 01:09:12PM +, 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 herb...@gondor.apana.org.au 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Questions about the Crypto API
On Thu, Aug 08, 2013 at 02:04:05PM +, 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 herb...@gondor.apana.org.au 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Questions about the Crypto API
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:herb...@gondor.apana.org.au] Sent: Friday, August 09, 2013 9:21 PM To: Hsieh, Che-Min Cc: Marcelo Cerri; linux-crypto@vger.kernel.org Subject: Re: Questions about the Crypto API On Thu, Aug 08, 2013 at 02:04:05PM +, 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 herb...@gondor.apana.org.au 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 majord...@vger.kernel.org More majordomo
RE: Questions about the Crypto API
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: linux-crypto-ow...@vger.kernel.org [mailto:linux-crypto-ow...@vger.kernel.org] On Behalf Of Herbert Xu Sent: Thursday, August 08, 2013 1:02 AM To: Marcelo Cerri Cc: linux-crypto@vger.kernel.org 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 herb...@gondor.apana.org.au 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Questions about the Crypto API
Hi Herbert -Original Message- From: linux-crypto-ow...@vger.kernel.org [mailto:linux-crypto- ow...@vger.kernel.org] On Behalf Of Herbert Xu Sent: Tuesday, August 06, 2013 12:30 PM To: Marcelo Cerri Cc: linux-crypto@vger.kernel.org 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/linux-crypto@vger.kernel.org/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 herb...@gondor.apana.org.au 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Questions about the Crypto API
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 herb...@gondor.apana.org.au 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. 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 herb...@gondor.apana.org.au 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Questions about the Crypto API
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Questions about the Crypto API
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
