ocf-linux-users — Anything and everything ocf-linux related

Re: [Ocf-linux-users] hardware acceleration question

[David M. <Dav...@se...>]

Jivin Max lays it down ...
> Hello.
> 
> After additional investigation it appeared that cryptotest choose wrong
> crypto_driver: after manually changing crypto_newsession() in crypto.c
> as follows:
> for (hid = 1; hid < crypto_drivers_num; hid++)...
> // note that hid is starting with 1 - that's where desired driver was 
> // registered
> I was able to run cryptotest on aes-7108 driver (only once however -
> after that /dev/crypto also disappeared).
> Unfortunately results were bad: I got "decrypt mismatch" error.

Ok that is the bug.

Attached is an older version that may still work for your kernel but fix
this problem.

> The next question is - what is the "iv" parameter printed by cryptotest?

http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation

> In order to clarify situation a bit I'd like to use reference aes
> implementation and to do so I need to get cleartext, cyphertext and key.
> That's pretty obvious except where is the key in cryptotest operations?

Load the cryptosoft driver instead of the aes-7108 driver.

Run cryptotest -v -a aes

That should get you the cleartext and cipher text.

To make it consistent, change the rdigit in cryptotest.c function to
return fixed values (there is an ifdef).

Cheers
Davidm

-- 
David McCullough,  dav...@se...,  Ph:+61 734352815
McAfee - SnapGear  http://www.snapgear.com                http://www.uCdot.org

Re: [Ocf-linux-users] hardware acceleration question

[Max <ma...@da...>]

Hello.

After additional investigation it appeared that cryptotest choose wrong
crypto_driver: after manually changing crypto_newsession() in crypto.c
as follows:
for (hid = 1; hid < crypto_drivers_num; hid++)...
// note that hid is starting with 1 - that's where desired driver was 
// registered
I was able to run cryptotest on aes-7108 driver (only once however -
after that /dev/crypto also disappeared).
Unfortunately results were bad: I got "decrypt mismatch" error.

The next question is - what is the "iv" parameter printed by cryptotest?
In order to clarify situation a bit I'd like to use reference aes
implementation and to do so I need to get cleartext, cyphertext and key.
That's pretty obvious except where is the key in cryptotest operations?

best regards,
Max.

Re: [Ocf-linux-users] hardware acceleration question

[Max <ma...@da...>]

Hello.

I double-checked and it seems that ocf do not see driver aes-7108 at
all: when I remove built-in aes support from linux kernel crypto api
(CONFIG_CRYPTO_AES option) when cryptotest says:
~ # cryptotest -v -c -a aes 4
cipher aes keylen 16
CIOCGSESSION: Invalid argument
hardware doesn't support algorithm; skip it

Here I'm stuck - aes-7108 driver is in kernel, it is initialized
(according to dmesg: cypher_7108_crypto_init(80113694)
7108: AES @ 0xbb500100 (0x1b500100 phys) CTR mode [3]) 
but ocf behaves like there is no such driver at all.

Do you have any idea what am I doing wrong?

best regards,
Max.

Re: [Ocf-linux-users] hardware acceleration question

[Max <ma...@da...>]

Hello.

I tried your patch but it doesn't compile with linux 2.6.12 due to lack
of linux/fdtable.h with files_fdtable() function used in
crypto/ocf/cryptodev.c:578

I attached troubled driver for Micronas 7108 - please feel free to
include it into ocf-linux.

thank you,
Max.

Re: [Ocf-linux-users] hardware acceleration question

[David M. <Dav...@se...>]

Jivin Max lays it down ...
> Thank you for support David.
> 
> I successfully moved driver aes-7108 to ocf-linux-20060331 and build
> appropriate crypto-tools.

Is the license on the aes-7108 driver suitable for inclusion into OCF proper ?
I'd be happy to help with updating it to the latest if it is.

> It's loaded ok:
> 
> ~ # dmesg|grep 71
> Peripheral DMA: Chip 0x7108
> cypher_7108_crypto_init(8011670c)
> 7108: AES @ 0xbb500100 (0x1b500100 phys) CTR mode
> 
> but openssl still failed to recognize it:
> 
> ~ # openssl engine
> Hardware
> cryptodev RSA
> cryptodev DSA
> cryptodev DH
> eng_cryptodev.c:1334 CIOCASYMFEAT - failure

The error is ok,  its just the public key bits failing.

> (cryptodev) BSD cryptodev engine
> (dynamic) Dynamic engine loading support
> 
> However cryptodev itself is present and usable:
> 
> ~ # openssl speed -elapsed -evp aes128 -engine cryptodev -cpu
> Hardware
> cryptodev RSA
> cryptodev DSA
> cryptodev DH
> eng_cryptodev.c:1334 CIOCASYMFEAT - failure
> engine "cryptodev" set.
> ...
> OpenSSL 0.9.8g 19 Oct 2007
> built on: Thu Apr 30 13:25:14 NOVST 2009
> options:bn(64,32) rc4(idx,int) des(idx,risc2,16,long) aes(partial)
> blowfish(idx) 
> compiler: mipsel-linux-gnu-gcc -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS
> -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN
> -I/home/x/pmc/linux-2.6.12-rc2-wis/include -DHAVE_CRYPTODEV -D__linux__
> -DTERMIO -O3 -fomit-frame-pointer -Wall
> ...
> 
> It looks like ocf driver aes-7108 is not used at all.
> 
> When I'm trying to run
> 
> ~ # cryptotest -v
> cipher 3des keylen 24
> CIOCGSESSION: Invalid argument

>From the name of the driver I am guessing it only does AES ?

If so try:

	cryptotest -a aes

> /dev/crypto disappear with no erros in dmesg.

That sounds like a bug from a long time ago.  It would be fixed in a later
version of ocf.  Using the current version would be ideal,  but it will
require changes to the aes-7108 driver.

> After this 
> 
> ~ # openssl engine
> ENGINE_load: failed to load cryptodev
> ENGINE_load: failed to load cryptodev
> (dynamic) Dynamic engine loading support
> 
> failed to find it.
> 
> I'll try to have a closer look at driver's source code and crypto-tools
> but right now it looks like there is either something wrong with ocf and
> \or driver (when called by cryptotest) or openssl (which fails to call
> it).
> 
> Any hints on what could be done next would be greatly appreciated.

I can generate you some patches which have some fixes in there,  but the
only way to have all the known problems fixed is to move to the newest
version availble.

I have attached one which should fix the /dev/crypto problem under 2.6
without changing too much other stuff (ie., you should not have to change
you driver).  Anything after this needs the driver to move to a new API.

Cheers,
Davidm

-- 
David McCullough,  dav...@se...,  Ph:+61 734352815
McAfee - SnapGear  http://www.snapgear.com                http://www.uCdot.org

Re: [Ocf-linux-users] hardware acceleration question

[Max <ma...@da...>]

Thank you for support David.

I successfully moved driver aes-7108 to ocf-linux-20060331 and build
appropriate crypto-tools.

It's loaded ok:

~ # dmesg|grep 71
Peripheral DMA: Chip 0x7108
cypher_7108_crypto_init(8011670c)
7108: AES @ 0xbb500100 (0x1b500100 phys) CTR mode

but openssl still failed to recognize it:

~ # openssl engine
Hardware
cryptodev RSA
cryptodev DSA
cryptodev DH
eng_cryptodev.c:1334 CIOCASYMFEAT - failure
(cryptodev) BSD cryptodev engine
(dynamic) Dynamic engine loading support

However cryptodev itself is present and usable:

~ # openssl speed -elapsed -evp aes128 -engine cryptodev -cpu
Hardware
cryptodev RSA
cryptodev DSA
cryptodev DH
eng_cryptodev.c:1334 CIOCASYMFEAT - failure
engine "cryptodev" set.
...
OpenSSL 0.9.8g 19 Oct 2007
built on: Thu Apr 30 13:25:14 NOVST 2009
options:bn(64,32) rc4(idx,int) des(idx,risc2,16,long) aes(partial)
blowfish(idx) 
compiler: mipsel-linux-gnu-gcc -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS
-D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN
-I/home/x/pmc/linux-2.6.12-rc2-wis/include -DHAVE_CRYPTODEV -D__linux__
-DTERMIO -O3 -fomit-frame-pointer -Wall
...

It looks like ocf driver aes-7108 is not used at all.

When I'm trying to run

~ # cryptotest -v
cipher 3des keylen 24
CIOCGSESSION: Invalid argument

/dev/crypto disappear with no erros in dmesg.

After this 

~ # openssl engine
ENGINE_load: failed to load cryptodev
ENGINE_load: failed to load cryptodev
(dynamic) Dynamic engine loading support

failed to find it.

I'll try to have a closer look at driver's source code and crypto-tools
but right now it looks like there is either something wrong with ocf and
\or driver (when called by cryptotest) or openssl (which fails to call
it).

Any hints on what could be done next would be greatly appreciated.

best regards,
Max.

Re: [Ocf-linux-users] hardware acceleration question

[David M. <Dav...@se...>]

Jivin Max lays it down ...
> I tried to compile crypto-tools-20080917.tar.gz but it failed - looks
> like it require newer version of ocf. What ocf & crypto-tools versions
> are recommended for linux kernel 2.6.12

Most would eb ok,  but you need ot match the sources.  From the last email,
get and older version of the crypto-tools archive.

> Also I tried to change dprintk to printk in aes-7108 driver and run
> speed -engine cryptodev aes-128-cbc
> and got nothing in dmesg.
> 
> It looks like openssl uses built-ni aes.
> 
> How do I it instruct to use particular cipher provided by aes-7108?
> How can I check which values for openssl are built-in and which are
> provided by aes-7108?

Check some of the command line options at:

	http://ocf-linux.sourceforge.net/benchmarks.html

Try turning on OCF debug (see the README) to see if OCF gets called or is
used.

Cheers,
Davidm

-- 
David McCullough,  dav...@se...,  Ph:+61 734352815
McAfee - SnapGear  http://www.snapgear.com                http://www.uCdot.org

Re: [Ocf-linux-users] hardware acceleration question

[David M. <Dav...@se...>]

Jivin Max lays it down ...
> Hello.
> 
> I tried to use crypto-tools as a test but it failed to compile with my
> ocf version (which is unknown).

You can get older versions of crypto-tools from sourceforge under the
ocf-linux project.

Get the oldest version,  it should work with just about anything IIRC.

> This brings up one more question - which version of ocf (and appropriate
> crypto-tools) is recommended to use with linux kernel 2.6.12?

Obviously you have a driver for your HW.  If you only have a binary then
stick with the version you have.

If you have source then it should not be too hard to bring it up to the
lastest ocf version (Sep 2008 IIRC).  If you find it too much then the
20060331 release is probably your next best bet.

Cheers,
Davidm

-- 
David McCullough,  dav...@se...,  Ph:+61 734352815
McAfee - SnapGear  http://www.snapgear.com                http://www.uCdot.org

Re: [Ocf-linux-users] hardware acceleration question

[Max <ma...@da...>]

I tried to compile crypto-tools-20080917.tar.gz but it failed - looks
like it require newer version of ocf. What ocf & crypto-tools versions
are recommended for linux kernel 2.6.12

Also I tried to change dprintk to printk in aes-7108 driver and run
speed -engine cryptodev aes-128-cbc
and got nothing in dmesg.

It looks like openssl uses built-ni aes.

How do I it instruct to use particular cipher provided by aes-7108?
How can I check which values for openssl are built-in and which are
provided by aes-7108?


best regards,
Max.

Re: [Ocf-linux-users] hardware acceleration question

[Max <ma...@da...>]

Hello.

I tried to use crypto-tools as a test but it failed to compile with my
ocf version (which is unknown).
This brings up one more question - which version of ocf (and appropriate
crypto-tools) is recommended to use with linux kernel 2.6.12?

best regards,
Max.

Re: [Ocf-linux-users] hardware acceleration question

[David M. <Dav...@se...>]

Jivin Max lays it down ...
> Some additional notes - looks like modules are fine:
> 
> ~ # lsmod
> Module                  Size  Used by    Tainted: P
> fuse 56688 0 - Live 0xc0033000
> aes_7108 9328 0 - Live 0xc001a000
> cryptosoft 8752 0 - Live 0xc0016000
> cryptodev 13936 0 - Live 0xc0009000
> ocf 27456 3 aes_7108,cryptosoft,cryptodev, Live 0xc000e000

Looks good.

Make sure you have a /dev/crypto:

	~> ls -al /dev/crypto
	crw-rw-rw-    1 root     root      10,  70 May 13 05:20 /dev/crypto

>From memory though you only have AES enabled in your kernel,  and cryptosoft
uses the kernels crypto, so if you need more alg's turn them on in your
kernel config.

> But ~ # openssl engine
> Hardware
> cryptodev RSA
> cryptodev DSA
> cryptodev DH
> eng_cryptodev.c:1334 CIOCASYMFEAT - failure
> (cryptodev) BSD cryptodev engine
> (dynamic) Dynamic engine loading support
> 
> Still failed to recognize it.
> 
> Do you have any ideas why could this happen?

Not really without stracing it or something.

Get the crypto-tools-20080917.tar.gz file and built cryptotest,
it talks directly to OCF and does not work if OCF is not working.

Just run "cryptotest" and it will do a single 3des test.

Something like:

	cryptotest -a aes

will do aes.

If it fails it will probably have an OK error message,
if not run "strace cryptotest".

Also try cryptotest -v

> Maybe some other tools I can use instead of openssl?

cryptotest is the easiest to work with to get things going,  from there move
to openssl,

Cheers,
Davidm

-- 
David McCullough,  dav...@se...,  Ph:+61 734352815
McAfee - SnapGear  http://www.snapgear.com                http://www.uCdot.org

Re: [Ocf-linux-users] hardware acceleration question

[Max <ma...@da...>]

Some additional notes - looks like modules are fine:

~ # lsmod
Module                  Size  Used by    Tainted: P
fuse 56688 0 - Live 0xc0033000
aes_7108 9328 0 - Live 0xc001a000
cryptosoft 8752 0 - Live 0xc0016000
cryptodev 13936 0 - Live 0xc0009000
ocf 27456 3 aes_7108,cryptosoft,cryptodev, Live 0xc000e000

But ~ # openssl engine
Hardware
cryptodev RSA
cryptodev DSA
cryptodev DH
eng_cryptodev.c:1334 CIOCASYMFEAT - failure
(cryptodev) BSD cryptodev engine
(dynamic) Dynamic engine loading support

Still failed to recognize it.

Do you have any ideas why could this happen?
Maybe some other tools I can use instead of openssl?

best regards,
Max.

Re: [Ocf-linux-users] hardware acceleration question

[Max <ma...@da...>]

Thank you for reply David.

В Срд, 13/05/2009 в 08:45 +1000, David McCullough пишет:
> You will need at least three drivers loaded, for example:
> 
> 	ocf 15616 3 cryptodev,ixp4xx, Live 0xc3d58000 (P)
> 	cryptodev 10180 0 - Live 0xc3d80000 (P)
> 	ixp4xx 7152 0 - Live 0xc3d74000

Is this expected output of dmesg?
I compiled ocf and appropriate drivers into kernel.

How could I check that driver is loaded and usable?
What should I do to track down reason why openssl failed to use it for
example?

best regards,
Max.

Re: [Ocf-linux-users] hardware acceleration question

[David M. <Dav...@se...>]

Jivin Max lays it down ...
> Hello.
> 
> I'm using ocf with pretty old kernel 2.6.12 to get hardware acceleration
> working with Micronas chips.
> 
> After compilation I got following:
> 
> openssl engine
> Hardware
> cryptodev RSA
> cryptodev DSA
> cryptodev DH
> eng_cryptodev.c:1334 CIOCASYMFEAT - failure
> (cryptodev) BSD cryptodev engine
> (dynamic) Dynamic engine loading support
> 
> ~ # cat /proc/crypto
> name         : aes
> module       : kernel
> type         : cipher
> blocksize    : 16
> min keysize  : 16
> max keysize  : 32
> 
> name         : crc32c
> module       : kernel
> type         : digest
> blocksize    : 32
> digestsize   : 4
> 
> It looks like ocf itself is loaded (/dev/crypto is present) but
> appropriate drivers are not. However I see messages from these drivers
> in dmesg:
> 
> ~ # dmesg |grep AES
> 7108: AES @ 0xbb500100 (0x1b500100 phys) CTR mode
> 8100: AES @ 0xb8500000 (0x18500000 phys) ctr mode
> 
> This looks confusing: how can I make sure that particular driver is
> loaded and will be use by openssl?
> If it's not loaded\used - what should I do to track problem?

/proc/crypto is not part of OCF,  that is the kernel crypto API.

Have you loaded the OCF modules (or compiled them into your kernel ?)

You will need at least three drivers loaded, for example:

	ocf 15616 3 cryptodev,ixp4xx, Live 0xc3d58000 (P)
	cryptodev 10180 0 - Live 0xc3d80000 (P)
	ixp4xx 7152 0 - Live 0xc3d74000

The drivers are:

	ocf       - the main ocf core
	cryptodev - the interface needed for user space access
	ixp4xx    - the ocf HW driver for this device,  you may have a different
	            one (safe/hifn/talitos/...) or use the SW version,
				cryptosoft.

If you use cryptosoft,  you need to add more algorithms to your kernel
crypto config for it to be of much use.

Cheers,
Davidm

-- 
David McCullough,  dav...@se...,  Ph:+61 734352815
McAfee - SnapGear  http://www.snapgear.com                http://www.uCdot.org

[Ocf-linux-users] hardware acceleration question

[Max <ma...@da...>]

Hello.

I'm using ocf with pretty old kernel 2.6.12 to get hardware acceleration
working with Micronas chips.

After compilation I got following:

openssl engine
Hardware
cryptodev RSA
cryptodev DSA
cryptodev DH
eng_cryptodev.c:1334 CIOCASYMFEAT - failure
(cryptodev) BSD cryptodev engine
(dynamic) Dynamic engine loading support

~ # cat /proc/crypto
name         : aes
module       : kernel
type         : cipher
blocksize    : 16
min keysize  : 16
max keysize  : 32

name         : crc32c
module       : kernel
type         : digest
blocksize    : 32
digestsize   : 4

It looks like ocf itself is loaded (/dev/crypto is present) but
appropriate drivers are not. However I see messages from these drivers
in dmesg:

~ # dmesg |grep AES
7108: AES @ 0xbb500100 (0x1b500100 phys) CTR mode
8100: AES @ 0xb8500000 (0x18500000 phys) ctr mode

This looks confusing: how can I make sure that particular driver is
loaded and will be use by openssl?
If it's not loaded\used - what should I do to track problem?

best regards,
Max.

Re: [Ocf-linux-users] Key accelerator support in OCF.

[Kennedy, B. <bre...@in...>]

Hi All,

There is an example of PKE related acceleration code in the 'ep80579' directory of the OCF release (see icp_common.c and icp_asym.c). It implements each of the OCF supported algorithms.

As an aside, for DSA verify, I attach a 2 patches for your appraisal. For OCF, the patch allows a verification failure (i.e. due to bad keys) to be treated separately from a process failure. The OpenSSL engine patch is required because openssl seems to take '1' as success, whereas OCF returns 0 for success.

Regards,
Brendan

OCF 20080917 patch:

--- ocf-linux/ocf/cryptodev.c   2007-12-14 02:35:04.000000000 +0000
+++ ocf-linux/ocf/cryptodev.c   2009-04-07 18:55:22.390311000 +0100
@@ -486,7 +486,6 @@ cryptodev_key(struct crypt_kop *kop)

        kop->crk_crid = krp->krp_crid;          /* device that did the work */
        if (krp->krp_status != 0) {
-               error = krp->krp_status;
                goto fail;
        }


OpenSSL 0.9.8e or g eng_cryptodev.c patch:

--- openssl/crypto/engine/eng_cryptodev.c       2008-12-03 14:21:46.000000000 +0000
+++ openssl.working/crypto/engine/eng_cryptodev.c       2008-12-02 18:32:47.000000000 +0000
@@ -1215,7 +1216,8 @@ cryptodev_dsa_verify(const unsigned char
        kop.crk_iparams = 7;

        if (cryptodev_asym(&kop, 0, NULL, 0, NULL) == 0) {
-               dsaret = kop.crk_status;
+/*OCF success value is 0, if not zero, change dsaret to fail*/
+               if(0 != kop.crk_status) dsaret  = 0;
        } else {
                const DSA_METHOD *meth = DSA_OpenSSL();




-----Original Message-----
From: David McCullough [mailto:Dav...@se...] 
Sent: 08 May 2009 01:05
To: anj...@mi...
Cc: ocf...@li...
Subject: Re: [Ocf-linux-users] Key accelerator support in OCF.


Jivin anj...@mi... lays it down ...
> Hi,
> I am developing OCF driver for the hardware which can off-load different 
> mathematical operations like "mod exponentiation", "mod mult", "mod inv", 
> etc...
> I see only "modular expo" can be off-loaded with current OCF frame work. 

Sorry for not replying earlier,  just spotted this in my inbox.

Currently there are examples/implementations of doing:

	MOD_EXP
	MOD_EXP_CRT

and rudimentary support for:

	DSA_SIGN
	DSA_VERIFY
	DH_COMPUTE_KEY

> Is there any support to off-load other math operations?
> With the current OCF frame work what all mathematical operations can be 
> off-loaded to hardware.

The API for the "math" like functions is pretty generic, you should be able
to easily add any operations you like really.

Basically you pass in a list of input/output params and the impementations
know what each param is for.

I have seen a driver that implemented much more than just the MOD_EXP,
can't recall any details of it though :-(

Cheers,
Davidm

-- 
David McCullough,  dav...@se...,  Ph:+61 734352815
McAfee - SnapGear  http://www.snapgear.com                http://www.uCdot.org

------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image 
processing features enabled. http://p.sf.net/sfu/kodak-com
_______________________________________________
Ocf-linux-users mailing list
Ocf...@li...
https://lists.sourceforge.net/lists/listinfo/ocf-linux-users
---------------------------------------------------------------------
Intel Shannon Limited
Registered in Ireland
Registered Office: One Spencer Dock, North Wall Quay, Dublin 1
Registered Number: 308263
Business address: Dromore House, East Park, Shannon, Co. Clare

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Re: [Ocf-linux-users] Key accelerator support in OCF.

[David M. <Dav...@se...>]

Jivin anj...@mi... lays it down ...
> Hi,
> I am developing OCF driver for the hardware which can off-load different 
> mathematical operations like "mod exponentiation", "mod mult", "mod inv", 
> etc...
> I see only "modular expo" can be off-loaded with current OCF frame work. 

Sorry for not replying earlier,  just spotted this in my inbox.

Currently there are examples/implementations of doing:

	MOD_EXP
	MOD_EXP_CRT

and rudimentary support for:

	DSA_SIGN
	DSA_VERIFY
	DH_COMPUTE_KEY

> Is there any support to off-load other math operations?
> With the current OCF frame work what all mathematical operations can be 
> off-loaded to hardware.

The API for the "math" like functions is pretty generic, you should be able
to easily add any operations you like really.

Basically you pass in a list of input/output params and the impementations
know what each param is for.

I have seen a driver that implemented much more than just the MOD_EXP,
can't recall any details of it though :-(

Cheers,
Davidm

-- 
David McCullough,  dav...@se...,  Ph:+61 734352815
McAfee - SnapGear  http://www.snapgear.com                http://www.uCdot.org

Re: [Ocf-linux-users] crypto_dispatch update for 20080917

[David M. <Dav...@se...>]

Jivin Kennedy, Brendan lays it down ...
> Hi David,
> 
> Thanks, that patch seems to be working as expected for some of my
> fail cases. However, the reason I have taken so long to get back to
> you (sorry!) is that I have encountered another problem, but I think
> it's in my own code. Anyway, I can't run a full set of tests on the
> change until it is fixed :/

I think I'll commit it,  all the other drivers are broken for failure cases
at the moment so better to improve things on that front :-)

Thanks,
Davidm

> -----Original Message-----
> From: David McCullough [mailto:Dav...@se...] 
> Sent: 30 April 2009 12:09
> To: Kennedy, Brendan
> Cc: ocf...@li...
> Subject: Re: [Ocf-linux-users] crypto_dispatch update for 20080917
> 
> 
> Jivin Kennedy, Brendan lays it down ...
> > Thanks David,
> > 
> > So is that patch going to be in the next release? :-) Just it definitely
> > changes how error cases need to be handled in the drivers...
> 
> If it fixes the problem you are seeing I will commit it and it will be in
> the next release :-)  I should do one really,  it has the 2.6.29 updates
> etc in there now and quite a few more little updates.
> 
> > Yep, it's EINVAL or EFAULT. The fault code seems to only matter if it's
> > ERESTART though??
> 
> Basically I just wanted to know what a driver was doing that would return
> an error other than full.  EINVAL sprang to mind if the kery sizes or
> something similar didn't match.
> 
> I was concerned if it was something that would normally happen,  as I
> haven't been seeing it myself.
> 
> Thanks again,
> 
> Cheers,
> Davidm
> 
> > -----Original Message-----
> > From: David McCullough [mailto:Dav...@se...] 
> > Sent: 30 April 2009 00:03
> > To: Kennedy, Brendan
> > Cc: ocf...@li...
> > Subject: Re: [Ocf-linux-users] crypto_dispatch update for 20080917
> > 
> > 
> > Jivin Kennedy, Brendan lays it down ...
> > > Hi All,
> > > 
> > > I am having trouble understanding the update to the crypto_dispatch function in crypto.c for ocf-linux-20080917 from ocf-linux-2071215:
> > > 
> > > 2007 code:
> > >                 if (!cap->cc_qblocked) {
> > >                         result = crypto_invoke(cap, crp, 0);
> > >                         if (result != ERESTART)
> > >                                 return (result);
> > > 
> > > 2008 code:
> > >                         result = crypto_invoke(cap, crp, 0);
> > >                         CRYPTO_Q_LOCK();
> > >                         if (result != ERESTART)
> > >                                 crypto_drivers[hid].cc_qblocked = 0;
> > > 
> > > In the 2008 code an error is not returned to cryptodev.c if crypto_invoke returns an error code.
> > > Should we now always call crypto_done() if there is a fail in the driver invoke function?
> > > 
> > > I ask because I've tried this but am getting a soft lockup when using crypto-tools and testing some fail case scenarios if I set the crp->etype before calling crypto-done.
> > 
> > Yeah,  I can't explain it either and I made that change.  It was part of a
> > SMP/locking problem and it looks like I lost the result code.  Here is a
> > quick patch (untested :-) that I think will return the functionality that
> > was lost.  Let me know how it goes.
> > 
> > Out of interest,  what is the condition error that the driver you are using
> > is reporting ?  EINVAL perhaps ?
> > 
> > Thanks for tracking this down,
> > 
> > Cheers,
> > Davidm
> > 
> > Index: ocf/crypto.c
> > ===================================================================
> > RCS file: ocf/crypto.c,v
> > retrieving revision 1.42
> > diff -u -r1.42 crypto.c
> > --- ocf/crypto.c	31 Mar 2009 00:41:14 -0000	1.42
> > +++ ocf/crypto.c	29 Apr 2009 23:01:08 -0000
> > @@ -838,13 +838,15 @@
> >  		 */
> >  		list_add(&crp->crp_next, &crp_q);
> >  		cryptostats.cs_blocks++;
> > +		result = 0;
> >  	} else if (result == -1) {
> >  		TAILQ_INSERT_TAIL(&crp_q, crp, crp_next);
> > +		result = 0;
> >  	}
> >  	if (crp_sleep)
> >  		wake_up_interruptible(&cryptoproc_wait);
> >  	CRYPTO_Q_UNLOCK();
> > -	return 0;
> > +	return result;
> >  }
> >  
> >  /*
> > 
> > 
> > -- 
> > David McCullough,  dav...@se...,  Ph:+61 734352815
> > McAfee - SnapGear  http://www.snapgear.com                http://www.uCdot.org
> > ---------------------------------------------------------------------
> > Intel Shannon Limited
> > Registered in Ireland
> > Registered Office: One Spencer Dock, North Wall Quay, Dublin 1
> > Registered Number: 308263
> > Business address: Dromore House, East Park, Shannon, Co. Clare
> > 
> > This e-mail and any attachments may contain confidential material for
> > the sole use of the intended recipient(s). Any review or distribution
> > by others is strictly prohibited. If you are not the intended
> > recipient, please contact the sender and delete all copies.
> > 
> 
> -- 
> David McCullough,  dav...@se...,  Ph:+61 734352815
> McAfee - SnapGear  http://www.snapgear.com                http://www.uCdot.org
> ---------------------------------------------------------------------
> Intel Shannon Limited
> Registered in Ireland
> Registered Office: One Spencer Dock, North Wall Quay, Dublin 1
> Registered Number: 308263
> Business address: Dromore House, East Park, Shannon, Co. Clare
> 
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
> 

-- 
David McCullough,  dav...@se...,  Ph:+61 734352815
McAfee - SnapGear  http://www.snapgear.com                http://www.uCdot.org

Re: [Ocf-linux-users] crypto_dispatch update for 20080917

[Kennedy, B. <bre...@in...>]

Hi David,

Thanks, that patch seems to be working as expected for some of my fail cases. However, the reason I have taken so long to get back to you (sorry!) is that I have encountered another problem, but I think it's in my own code. Anyway, I can't run a full set of tests on the change until it is fixed :/

Regards,
Brendan

-----Original Message-----
From: David McCullough [mailto:Dav...@se...] 
Sent: 30 April 2009 12:09
To: Kennedy, Brendan
Cc: ocf...@li...
Subject: Re: [Ocf-linux-users] crypto_dispatch update for 20080917


Jivin Kennedy, Brendan lays it down ...
> Thanks David,
> 
> So is that patch going to be in the next release? :-) Just it definitely
> changes how error cases need to be handled in the drivers...

If it fixes the problem you are seeing I will commit it and it will be in
the next release :-)  I should do one really,  it has the 2.6.29 updates
etc in there now and quite a few more little updates.

> Yep, it's EINVAL or EFAULT. The fault code seems to only matter if it's
> ERESTART though??

Basically I just wanted to know what a driver was doing that would return
an error other than full.  EINVAL sprang to mind if the kery sizes or
something similar didn't match.

I was concerned if it was something that would normally happen,  as I
haven't been seeing it myself.

Thanks again,

Cheers,
Davidm

> -----Original Message-----
> From: David McCullough [mailto:Dav...@se...] 
> Sent: 30 April 2009 00:03
> To: Kennedy, Brendan
> Cc: ocf...@li...
> Subject: Re: [Ocf-linux-users] crypto_dispatch update for 20080917
> 
> 
> Jivin Kennedy, Brendan lays it down ...
> > Hi All,
> > 
> > I am having trouble understanding the update to the crypto_dispatch function in crypto.c for ocf-linux-20080917 from ocf-linux-2071215:
> > 
> > 2007 code:
> >                 if (!cap->cc_qblocked) {
> >                         result = crypto_invoke(cap, crp, 0);
> >                         if (result != ERESTART)
> >                                 return (result);
> > 
> > 2008 code:
> >                         result = crypto_invoke(cap, crp, 0);
> >                         CRYPTO_Q_LOCK();
> >                         if (result != ERESTART)
> >                                 crypto_drivers[hid].cc_qblocked = 0;
> > 
> > In the 2008 code an error is not returned to cryptodev.c if crypto_invoke returns an error code.
> > Should we now always call crypto_done() if there is a fail in the driver invoke function?
> > 
> > I ask because I've tried this but am getting a soft lockup when using crypto-tools and testing some fail case scenarios if I set the crp->etype before calling crypto-done.
> 
> Yeah,  I can't explain it either and I made that change.  It was part of a
> SMP/locking problem and it looks like I lost the result code.  Here is a
> quick patch (untested :-) that I think will return the functionality that
> was lost.  Let me know how it goes.
> 
> Out of interest,  what is the condition error that the driver you are using
> is reporting ?  EINVAL perhaps ?
> 
> Thanks for tracking this down,
> 
> Cheers,
> Davidm
> 
> Index: ocf/crypto.c
> ===================================================================
> RCS file: ocf/crypto.c,v
> retrieving revision 1.42
> diff -u -r1.42 crypto.c
> --- ocf/crypto.c	31 Mar 2009 00:41:14 -0000	1.42
> +++ ocf/crypto.c	29 Apr 2009 23:01:08 -0000
> @@ -838,13 +838,15 @@
>  		 */
>  		list_add(&crp->crp_next, &crp_q);
>  		cryptostats.cs_blocks++;
> +		result = 0;
>  	} else if (result == -1) {
>  		TAILQ_INSERT_TAIL(&crp_q, crp, crp_next);
> +		result = 0;
>  	}
>  	if (crp_sleep)
>  		wake_up_interruptible(&cryptoproc_wait);
>  	CRYPTO_Q_UNLOCK();
> -	return 0;
> +	return result;
>  }
>  
>  /*
> 
> 
> -- 
> David McCullough,  dav...@se...,  Ph:+61 734352815
> McAfee - SnapGear  http://www.snapgear.com                http://www.uCdot.org
> ---------------------------------------------------------------------
> Intel Shannon Limited
> Registered in Ireland
> Registered Office: One Spencer Dock, North Wall Quay, Dublin 1
> Registered Number: 308263
> Business address: Dromore House, East Park, Shannon, Co. Clare
> 
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
> 

-- 
David McCullough,  dav...@se...,  Ph:+61 734352815
McAfee - SnapGear  http://www.snapgear.com                http://www.uCdot.org
---------------------------------------------------------------------
Intel Shannon Limited
Registered in Ireland
Registered Office: One Spencer Dock, North Wall Quay, Dublin 1
Registered Number: 308263
Business address: Dromore House, East Park, Shannon, Co. Clare

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Re: [Ocf-linux-users] crypto_dispatch update for 20080917

[David M. <Dav...@se...>]

Jivin Kennedy, Brendan lays it down ...
> Thanks David,
> 
> So is that patch going to be in the next release? :-) Just it definitely
> changes how error cases need to be handled in the drivers...

If it fixes the problem you are seeing I will commit it and it will be in
the next release :-)  I should do one really,  it has the 2.6.29 updates
etc in there now and quite a few more little updates.

> Yep, it's EINVAL or EFAULT. The fault code seems to only matter if it's
> ERESTART though??

Basically I just wanted to know what a driver was doing that would return
an error other than full.  EINVAL sprang to mind if the kery sizes or
something similar didn't match.

I was concerned if it was something that would normally happen,  as I
haven't been seeing it myself.

Thanks again,

Cheers,
Davidm

> -----Original Message-----
> From: David McCullough [mailto:Dav...@se...] 
> Sent: 30 April 2009 00:03
> To: Kennedy, Brendan
> Cc: ocf...@li...
> Subject: Re: [Ocf-linux-users] crypto_dispatch update for 20080917
> 
> 
> Jivin Kennedy, Brendan lays it down ...
> > Hi All,
> > 
> > I am having trouble understanding the update to the crypto_dispatch function in crypto.c for ocf-linux-20080917 from ocf-linux-2071215:
> > 
> > 2007 code:
> >                 if (!cap->cc_qblocked) {
> >                         result = crypto_invoke(cap, crp, 0);
> >                         if (result != ERESTART)
> >                                 return (result);
> > 
> > 2008 code:
> >                         result = crypto_invoke(cap, crp, 0);
> >                         CRYPTO_Q_LOCK();
> >                         if (result != ERESTART)
> >                                 crypto_drivers[hid].cc_qblocked = 0;
> > 
> > In the 2008 code an error is not returned to cryptodev.c if crypto_invoke returns an error code.
> > Should we now always call crypto_done() if there is a fail in the driver invoke function?
> > 
> > I ask because I've tried this but am getting a soft lockup when using crypto-tools and testing some fail case scenarios if I set the crp->etype before calling crypto-done.
> 
> Yeah,  I can't explain it either and I made that change.  It was part of a
> SMP/locking problem and it looks like I lost the result code.  Here is a
> quick patch (untested :-) that I think will return the functionality that
> was lost.  Let me know how it goes.
> 
> Out of interest,  what is the condition error that the driver you are using
> is reporting ?  EINVAL perhaps ?
> 
> Thanks for tracking this down,
> 
> Cheers,
> Davidm
> 
> Index: ocf/crypto.c
> ===================================================================
> RCS file: ocf/crypto.c,v
> retrieving revision 1.42
> diff -u -r1.42 crypto.c
> --- ocf/crypto.c	31 Mar 2009 00:41:14 -0000	1.42
> +++ ocf/crypto.c	29 Apr 2009 23:01:08 -0000
> @@ -838,13 +838,15 @@
>  		 */
>  		list_add(&crp->crp_next, &crp_q);
>  		cryptostats.cs_blocks++;
> +		result = 0;
>  	} else if (result == -1) {
>  		TAILQ_INSERT_TAIL(&crp_q, crp, crp_next);
> +		result = 0;
>  	}
>  	if (crp_sleep)
>  		wake_up_interruptible(&cryptoproc_wait);
>  	CRYPTO_Q_UNLOCK();
> -	return 0;
> +	return result;
>  }
>  
>  /*
> 
> 
> -- 
> David McCullough,  dav...@se...,  Ph:+61 734352815
> McAfee - SnapGear  http://www.snapgear.com                http://www.uCdot.org
> ---------------------------------------------------------------------
> Intel Shannon Limited
> Registered in Ireland
> Registered Office: One Spencer Dock, North Wall Quay, Dublin 1
> Registered Number: 308263
> Business address: Dromore House, East Park, Shannon, Co. Clare
> 
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
> 

-- 
David McCullough,  dav...@se...,  Ph:+61 734352815
McAfee - SnapGear  http://www.snapgear.com                http://www.uCdot.org

Re: [Ocf-linux-users] crypto_dispatch update for 20080917

[Kennedy, B. <bre...@in...>]

Thanks David,

So is that patch going to be in the next release? :-) Just it definitely changes how error cases need to be handled in the drivers...

Yep, it's EINVAL or EFAULT. The fault code seems to only matter if it's ERESTART though??

Regards,
Brendan

-----Original Message-----
From: David McCullough [mailto:Dav...@se...] 
Sent: 30 April 2009 00:03
To: Kennedy, Brendan
Cc: ocf...@li...
Subject: Re: [Ocf-linux-users] crypto_dispatch update for 20080917


Jivin Kennedy, Brendan lays it down ...
> Hi All,
> 
> I am having trouble understanding the update to the crypto_dispatch function in crypto.c for ocf-linux-20080917 from ocf-linux-2071215:
> 
> 2007 code:
>                 if (!cap->cc_qblocked) {
>                         result = crypto_invoke(cap, crp, 0);
>                         if (result != ERESTART)
>                                 return (result);
> 
> 2008 code:
>                         result = crypto_invoke(cap, crp, 0);
>                         CRYPTO_Q_LOCK();
>                         if (result != ERESTART)
>                                 crypto_drivers[hid].cc_qblocked = 0;
> 
> In the 2008 code an error is not returned to cryptodev.c if crypto_invoke returns an error code.
> Should we now always call crypto_done() if there is a fail in the driver invoke function?
> 
> I ask because I've tried this but am getting a soft lockup when using crypto-tools and testing some fail case scenarios if I set the crp->etype before calling crypto-done.

Yeah,  I can't explain it either and I made that change.  It was part of a
SMP/locking problem and it looks like I lost the result code.  Here is a
quick patch (untested :-) that I think will return the functionality that
was lost.  Let me know how it goes.

Out of interest,  what is the condition error that the driver you are using
is reporting ?  EINVAL perhaps ?

Thanks for tracking this down,

Cheers,
Davidm

Index: ocf/crypto.c
===================================================================
RCS file: ocf/crypto.c,v
retrieving revision 1.42
diff -u -r1.42 crypto.c
--- ocf/crypto.c	31 Mar 2009 00:41:14 -0000	1.42
+++ ocf/crypto.c	29 Apr 2009 23:01:08 -0000
@@ -838,13 +838,15 @@
 		 */
 		list_add(&crp->crp_next, &crp_q);
 		cryptostats.cs_blocks++;
+		result = 0;
 	} else if (result == -1) {
 		TAILQ_INSERT_TAIL(&crp_q, crp, crp_next);
+		result = 0;
 	}
 	if (crp_sleep)
 		wake_up_interruptible(&cryptoproc_wait);
 	CRYPTO_Q_UNLOCK();
-	return 0;
+	return result;
 }
 
 /*


-- 
David McCullough,  dav...@se...,  Ph:+61 734352815
McAfee - SnapGear  http://www.snapgear.com                http://www.uCdot.org
---------------------------------------------------------------------
Intel Shannon Limited
Registered in Ireland
Registered Office: One Spencer Dock, North Wall Quay, Dublin 1
Registered Number: 308263
Business address: Dromore House, East Park, Shannon, Co. Clare

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Re: [Ocf-linux-users] crypto_dispatch update for 20080917

[David M. <Dav...@se...>]

Jivin Kennedy, Brendan lays it down ...
> Hi All,
> 
> I am having trouble understanding the update to the crypto_dispatch function in crypto.c for ocf-linux-20080917 from ocf-linux-2071215:
> 
> 2007 code:
>                 if (!cap->cc_qblocked) {
>                         result = crypto_invoke(cap, crp, 0);
>                         if (result != ERESTART)
>                                 return (result);
> 
> 2008 code:
>                         result = crypto_invoke(cap, crp, 0);
>                         CRYPTO_Q_LOCK();
>                         if (result != ERESTART)
>                                 crypto_drivers[hid].cc_qblocked = 0;
> 
> In the 2008 code an error is not returned to cryptodev.c if crypto_invoke returns an error code.
> Should we now always call crypto_done() if there is a fail in the driver invoke function?
> 
> I ask because I've tried this but am getting a soft lockup when using crypto-tools and testing some fail case scenarios if I set the crp->etype before calling crypto-done.

Yeah,  I can't explain it either and I made that change.  It was part of a
SMP/locking problem and it looks like I lost the result code.  Here is a
quick patch (untested :-) that I think will return the functionality that
was lost.  Let me know how it goes.

Out of interest,  what is the condition error that the driver you are using
is reporting ?  EINVAL perhaps ?

Thanks for tracking this down,

Cheers,
Davidm

Index: ocf/crypto.c
===================================================================
RCS file: ocf/crypto.c,v
retrieving revision 1.42
diff -u -r1.42 crypto.c
--- ocf/crypto.c	31 Mar 2009 00:41:14 -0000	1.42
+++ ocf/crypto.c	29 Apr 2009 23:01:08 -0000
@@ -838,13 +838,15 @@
 		 */
 		list_add(&crp->crp_next, &crp_q);
 		cryptostats.cs_blocks++;
+		result = 0;
 	} else if (result == -1) {
 		TAILQ_INSERT_TAIL(&crp_q, crp, crp_next);
+		result = 0;
 	}
 	if (crp_sleep)
 		wake_up_interruptible(&cryptoproc_wait);
 	CRYPTO_Q_UNLOCK();
-	return 0;
+	return result;
 }
 
 /*


-- 
David McCullough,  dav...@se...,  Ph:+61 734352815
McAfee - SnapGear  http://www.snapgear.com                http://www.uCdot.org

[Ocf-linux-users] crypto_dispatch update for 20080917

[Kennedy, B. <bre...@in...>]

Hi All,

I am having trouble understanding the update to the crypto_dispatch function in crypto.c for ocf-linux-20080917 from ocf-linux-2071215:

2007 code:
                if (!cap->cc_qblocked) {
                        result = crypto_invoke(cap, crp, 0);
                        if (result != ERESTART)
                                return (result);

2008 code:
                        result = crypto_invoke(cap, crp, 0);
                        CRYPTO_Q_LOCK();
                        if (result != ERESTART)
                                crypto_drivers[hid].cc_qblocked = 0;

In the 2008 code an error is not returned to cryptodev.c if crypto_invoke returns an error code.
Should we now always call crypto_done() if there is a fail in the driver invoke function?

I ask because I've tried this but am getting a soft lockup when using crypto-tools and testing some fail case scenarios if I set the crp->etype before calling crypto-done.

Best Regards,
Brendan

------------------------------------------------
Brendan Kennedy
Intel Shannon Ltd.,
Ireland.

Email: bre...@in...<mailto:bre...@in...>
------------------------------------------------

---------------------------------------------------------------------
Intel Shannon Limited
Registered in Ireland
Registered Office: One Spencer Dock, North Wall Quay, Dublin 1
Registered Number: 308263
Business address: Dromore House, East Park, Shannon, Co. Clare

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

[Ocf-linux-users] Key accelerator support in OCF.

[<anj...@mi...>]

Hi,
I am developing OCF driver for the hardware which can off-load different 
mathematical operations like "mod exponentiation", "mod mult", "mod inv", 
etc...
I see only "modular expo" can be off-loaded with current OCF frame work. 
Is there any support to off-load other math operations?
With the current OCF frame work what all mathematical operations can be 
off-loaded to hardware.

Thanks
Anji

Re: [Ocf-linux-users] 64 bit support in OCF

[Vrabete, B. <bra...@in...>]

---------------------------------------------------------------------
Intel Shannon Limited
Registered in Ireland
Registered Office: One Spencer Dock, North Wall Quay, Dublin 1
Registered Number: 308263
Business address: Dromore House, East Park, Shannon, Co. Clare

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.