Re: [Ocf-linux-users] question about a custom HW crypto driver

[Amir T. <ami...@pe...>]

Hello David,

Thanks for your previous help and pointers. I modified my driver to register as a async block cipher. However, now it seems my driver functions are not getting called at all when I run cryptotest, even though it seems that the driver is registered correctly.
I've included the relevant init code snippet and the output of /proc/crypto.


Thanks,
Amir Tsvitov


Init code:
...
static struct crypto_alg cbc_aes_alg = {
	.cra_name			=	"cbc(aes)",
	.cra_driver_name		=	"hw-cbc-aes-async",
	.cra_priority		=	300,
	.cra_flags			=	CRYPTO_ALG_TYPE_ABLKCIPHER | CRYPTO_ALG_ASYNC,
	.cra_blocksize		=	AES_BLOCK_SIZE,
	.cra_ctxsize		=	sizeof(struct hw_aes_ctx),
	.cra_type			=	&crypto_ablkcipher_type,
	.cra_module			=	THIS_MODULE,
	.cra_init			=	cbc_aes_init,
	.cra_ablkcipher     = {
		.setkey	 = cbc_aes_set_key,
		.encrypt 	 = cbc_aes_encrypt,
		.decrypt     = cbc_aes_decrypt,
	},
	.cra_u			=	{
		.ablkcipher = {
			.min_keysize		=	AES_MIN_KEY_SIZE,
			.max_keysize		=	AES_MAX_KEY_SIZE,
			.ivsize			=	AES_BLOCK_SIZE,
		}
	}
};
...
crypto_register_alg(&cbc_aes_alg);


> -----Original Message-----
> From: David McCullough [mailto:Dav...@se...]
> Sent: Wednesday, August 05, 2009 4:51 PM
> To: Amir Tsvitov
> Cc: ocf...@li...
> Subject: Re: [Ocf-linux-users] question about a custom HW crypto driver
> 
> 
> Jivin Amir Tsvitov lays it down ...
> > Hello,
> >
> > I finished writing a Linux device driver for a custom crypto
> accelerator
> > and after testing it am now in the process of adapting it to work
> with
> > OCF Linux.
> >
> > I would greatly appreciate some pointers on some problems I
> encountered.
> >
> > 1.       The driver uses DMA to fetch the input and then write the
> output
> > after the crypto operation has completed. In my test version I put
> the call
> > to sleep on a wait queue which then gets woken up by the DMA done
> ISR.
> > I tried a similar approach with my OCF version but get scheduling
> panic
> > messages from the kernel.  What is the proper way to suspend the call
> > until the DMA transfer has completed?
> 
> You don't :-)
> 
> Both the safei, hifn7751 and talitos drivers use DMA in much the same
> way.
> They are reasonable drivers to use as an example.
> 
> Here is the basic idea for your driver:
> 
> 	mydriver_process(..)
> 		...
> 		set up DMA fetch to send data to HW
> 		signal chip to do it
> 		...
> 		return OK
> 
> 	mydriver_interrupt()
> 		...
> 		request is complete
> 			do callback with status
> 
> You don't need to wait anywhere as OCF is asynchronous,  you just have
> your
> interrupt routine call back one the crypto processing is complete.
> 
> Now a real drover will be much more complex and involved,  but if you
> look
> at the other drivers you should be able to get the idea,
> 
> > 2.       As a temporary hack until I figure out #1 I am currently
> polling
> > to see when the operation has completed. Using openssl (with an OCF
> patch)
> > I ran the following commands:
> >
> > openssl aes-128-cbc -a -salt -in test.txt -out test.txt.enc -pass
> pass:amir123
> >
> > openssl aes-128-cbc -d -a -in test.txt.enc  -out test.txt.dec -k
> amir123
> >
> > where test.txt is:
> >
> >                 This is a test 123456789 line 1
> >
> > This is a test 123456789 line 2
> >
> > This is a test 123456789 line 3
> >
> > ….
> >
> > This is a test 123456789 line 18
> >
> > This is a test 123456789 line 19
> >
> > This is a test 123456789 line 20
> >
> >
> >
> > I get the following error:
> >
> > bad decrypt
> >
> > 1023:error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad
> decrypt:evp_enc.c:461:
> >
> >
> >
> >          And the contents of the  resulting test.txt.dec are:
> >
> >          &£f6Š4˜           uyVֳue23456789 line 1
> >
> >          This is a test 123456789 line 2
> >
> >          This is a test 123456789 line 3
> >
> > ...
> >
> >  This is a test 123456789 line 18
> >
> >  This is a test 123456789 line 19
> >
> >  This is a test 123456
> >
> >
> >
> > So  for some reason I am getting garbage in the beginning of the
> > decrypted message and missing other data at the end of it?
> 
> Hard to say really, use cryptotest to debug,  it is much easier to
> follow
> than the SSL code,
> 
> Cheers,
> Davidm
> 
> --
> David McCullough,  dav...@se...,  Ph:+61
> 734352815
> McAfee - SnapGear  http://www.snapgear.com
> http://www.uCdot.org