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
