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

[Ocf-linux-users] Cryptotest changes

[Schuurman, H. <he...@ti...>]

Hi David,

The current version of cryptotest from the crypto-tools-20100325.tar.gz package only tests the sha256_hmac, and not the md5_hmac, sha1_hmac, sha384_hmac, and sha512_hmac (if available).  This happens because the authkey length settings don't match between crypto/ocf/cryptodev.c and cryptotest.c.

Crypto/ocf/cryptodev.c uses the following settings for authkey, based on the operation (see cryptodev_ioctl()):

    CRYPTO_MD5_HMAC        16
    CRYPTO_SHA1_HMAC       20
    CRYPTO_SHA2_256_HMAC   32
    CRYPTO_SHA2_384_HMAC   48
    CRYPTO_SHA2_512_HMAC   64

Cryptotest.c uses the alg structure table to compute the authkey length:

    { "md5",            1,    8,    0,    0,        16,    CRYPTO_MD5 },
    { "md5_hmac",       1,    8,    1,    64,       16,    CRYPTO_MD5_HMAC },
    { "sha1",           1,    8,    0,    0,        20,    CRYPTO_SHA1 },
    { "sha1_hmac",      1,    1,    1,    64,       20,    CRYPTO_SHA1_HMAC },
    { "sha256",         1,    8,    0,    0,        32,    CRYPTO_SHA2_256 },
    { "sha256_hmac",    1,    1,    1,    64,       32,    CRYPTO_SHA2_256_HMAC },
    { "sha384",         1,    8,    0,    0,        48,    CRYPTO_SHA2_384 },
    { "sha384_hmac",    1,    1,    1,    64,       48,    CRYPTO_SHA2_384_HMAC },
    { "sha512",         1,    8,    0,    0,        64,    CRYPTO_SHA2_512 },
    { "sha512_hmac",    1,    1,    1,    64,       64,    CRYPTO_SHA2_512_HMAC },

All _hmac entries show a minkeylen/maxkeylen value of 1/64.  This causes runtest() to pass a keylen of (1+64)/2 = 32, which only works for the sha256_hmac.  Changing the table entries in cryptotest.c to:

    { "md5",            1,    8,    0,    0,        16,    CRYPTO_MD5 },
    { "md5_hmac",       1,    8,    16,   16,       16,    CRYPTO_MD5_HMAC },
    { "sha1",           1,    8,    0,    0,        20,    CRYPTO_SHA1 },
    { "sha1_hmac",      1,    1,    20,   20,       20,    CRYPTO_SHA1_HMAC },
    { "sha256",         1,    8,    0,    0,        32,    CRYPTO_SHA2_256 },
    { "sha256_hmac",    1,    1,    32,   32,       32,    CRYPTO_SHA2_256_HMAC },
    { "sha384",         1,    8,    0,    0,        48,    CRYPTO_SHA2_384 },
    { "sha384_hmac",    1,    1,    48,   48,       48,    CRYPTO_SHA2_384_HMAC },
    { "sha512",         1,    8,    0,    0,        64,    CRYPTO_SHA2_512 },
    { "sha512_hmac",    1,    1,    64,   64,       64,    CRYPTO_SHA2_512_HMAC },

allows cryptotest to test the other *_hmacs too.

Best regards,

Herman Schuurman

[Ocf-linux-users] Cryptosoft problem...

[Schuurman, H. <he...@ti...>]

Hi David,

It looks like the OCF cryptosoft driver is not terminating scatterlists correctly.  The problem shows up if a crypto API hardware driver relies on sg_next() to return NULL at the end of a scatterlist chain, eventually leading to a bad pointer reference if the end is not marked correctly.

The following change to crypto/ocf/cryptosoft.c looks like it resolves the problem:

	*** crypto/ocf/cryptosoft.c 2011-11-18 16:00:50.399693999 -0600
	--- crypto/ocf/cryptosoft.c 2012-01-25 11:45:48.637623644 -0600
	***************
	*** 814,819 ****
	--- 814,820 ----
	                     sg_len, offset_in_page(crp->crp_buf + skip));
	              sg_num = 1;
	       }
	+      sg_mark_end(&req->sg[sg_num-1]);
	  
	       switch (sw->sw_type & SW_TYPE_ALG_AMASK) {

This marks the last sg entry written with sg_mark_end().

Best regards,

Herman Schuurman

[Ocf-linux-users] Question regarding the operation of AES 128 CBC mode with OCF

[Sundar S. <sun...@gm...>]

Thanks for the suggestions David,

I open up the session only once and continue all my encryption/decryption
before closing it, and it works.
As you said, opening and closing sessions for each crypto operation costs
lot of cpu cycles dearly :)

Still am not sure if my crypto driver is supporting the chaining mode by
feeding the cipher as the next IV.
I don't think it is done by OCF in the kernel space nor in the user space
API.
It is proper only if chaining is taken care by the driver or the crypto
hardware internally, for performance reasons.
And also partly because this is specific only to certain algorithms. I'll
check with my vendor for clarifications on the chaining mode.

I've got another problem with openssl-0.9.8.r OCF patch. Am using an ARM
SoC.
The problem is that TLS/SSL certificate verification always fails due to
?endianess? issues.

There is no "Configure" option in openssl-0.9.8r for armv4 so I compiled
with linux-generic32 or linux-elf.
It is a little endian ARM machine to be precise. Supports v7a instruction
set if that matters. I also tried a custom OCF patch meant for
openssl-0.9.8r ported to openssl-1.0.0e but has got some other issues.
It crashes for some reason :(

Could you please let me know if there is an OCF patch available for
openssl-1.0.0x versions? And is known to be working on ARM machines?

Thanks in advance!

Regards,
Sundar


On Wed, Dec 7, 2011 at 9:28 AM, David McCullough <
dav...@mc...> wrote:

>
> Jivin Sundar Subramaniyan lays it down ...
> > Hi OCF guys,
> >
> > I have OCF framework along with the drivers built into the kernel and
> properly tested with crypto-tools (cmactest and cryptotest).
> >
> > My question is particularly about the AES 128 CBC mode.
> >
> > The cmactest.c under crypto-tools had test code for sha1 hmac and des
> hmac.
> >
> > I followed the same procedure for testing aes 128 cbc and it seemed to
> work.
> >
> > 1. First I open up a session with keylength and key, etc,
> > 2. Secondly, encrypt a plain text with an IV.
> > 3. Then decrypt the cipher text that is obtained in step two.
> > 4. Close the session
> >
> > In CBC mode, the IV is fed only the first time. The encryption of
> forthcoming plaintext is done with the previous ciphertext as the IV.
> > Should I keep the previous ciphertext somewhere in the userland
> application and feed it the next time as the IV for next encryption?
>
> I think you need to take care of that but I haven't had time to check it
> out
> properly.
>
> > Or this chaining is taken care by OCF/driver in the kernel?
> >
> > If it happens in the OCF in kernel space, then is it ok that i close the
> session for every encryption/decryption?
> > I guess the session should be kept till all the encryption/decryption is
> over.
>
> If you can,  open the session once and close it when you are finished.
> Opening/closing all the time will just slow you down :-)
>
> Cheers,
> Davidm
>
> --
> David McCullough,      dav...@mc...,  Ph:+61 734352815
> McAfee - SnapGear      http://www.mcafee.com         http://www.uCdot.org
>

Re: [Ocf-linux-users] Question regarding the operation of AES 128 CBC mode with OCF

[David M. <dav...@mc...>]

Jivin Sundar Subramaniyan lays it down ...
> Hi OCF guys,
> 
> I have OCF framework along with the drivers built into the kernel and properly tested with crypto-tools (cmactest and cryptotest).
> 
> My question is particularly about the AES 128 CBC mode.
> 
> The cmactest.c under crypto-tools had test code for sha1 hmac and des hmac.
> 
> I followed the same procedure for testing aes 128 cbc and it seemed to work. 
> 
> 1. First I open up a session with keylength and key, etc,
> 2. Secondly, encrypt a plain text with an IV.
> 3. Then decrypt the cipher text that is obtained in step two.
> 4. Close the session
> 
> In CBC mode, the IV is fed only the first time. The encryption of forthcoming plaintext is done with the previous ciphertext as the IV.
> Should I keep the previous ciphertext somewhere in the userland application and feed it the next time as the IV for next encryption?

I think you need to take care of that but I haven't had time to check it out
properly.

> Or this chaining is taken care by OCF/driver in the kernel?
> 
> If it happens in the OCF in kernel space, then is it ok that i close the session for every encryption/decryption?
> I guess the session should be kept till all the encryption/decryption is over.

If you can,  open the session once and close it when you are finished.
Opening/closing all the time will just slow you down :-)

Cheers,
Davidm

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

[Ocf-linux-users] Question regarding the operation of AES 128 CBC mode with OCF

[Sundar S. <sun...@gm...>]

Hi OCF guys,

I have OCF framework along with the drivers built into the kernel and
properly tested with crypto-tools (cmactest and cryptotest).

My question is particularly about the AES 128 CBC mode.

The cmactest.c under crypto-tools had test code for sha1 hmac and des hmac.

I followed the same procedure for testing aes 128 cbc and it seemed to
work.

1. First I open up a session with keylength and key, etc,
2. Secondly, encrypt a plain text with an IV.
3. Then decrypt the cipher text that is obtained in step two.
4. Close the session

In CBC mode, the IV is fed only the first time. The encryption of
forthcoming plaintext is done with the previous ciphertext as the IV.
Should I keep the previous ciphertext somewhere in the userland application
and feed it the next time as the IV for next encryption?
Or this chaining is taken care by OCF/driver in the kernel?

If it happens in the OCF in kernel space, then is it ok that i close the
session for every encryption/decryption?
I guess the session should be kept till all the encryption/decryption is
over.

Thanks in advance for clarification.

Regards,
Sundar

Re: [Ocf-linux-users] Marvell CESA: platform_data

[<ana...@wi...>]

Thanks for the reply.

 

orion_crypto_init() has no code to initialize platform_data in orion_crypto device. I would think it should be done one of the ways as follows (as examples).

 

static struct platform_device orion_ge11_shared = {

        .name           = MV643XX_ETH_SHARED_NAME,

        .id             = 1,

        .dev            = {

                .platform_data  = &orion_ge11_shared_data,

        },

};

 

OR

 

void __init orion_ge00_switch_init(struct dsa_platform_data *d, int irq)

{

        int i;

 

        if (irq != NO_IRQ) {

                orion_switch_resources[0].start = irq;

                orion_switch_resources[0].end = irq;

                orion_switch_device.num_resources = 1;

        }

 

        d->netdev = &orion_ge00.dev;

        for (i = 0; i < d->nr_chips; i++)

                d->chip[i].mii_bus = &orion_ge00_shared.dev;

        orion_switch_device.dev.platform_data = d;

 

        platform_device_register(&orion_switch_device);

}

 

The same is not done for crypto device. Or am I missing something?

 

Regards

Ananth

From: 张绪峰 [mailto:sea...@12...] 
Sent: Tuesday, November 22, 2011 10:39 AM
To: Anantharam V (WT01 - GMT-Telecom Equipment)
Cc: ocf...@li...
Subject: Re:[Ocf-linux-users] Marvell CESA: platform_data

 

 

 



At 2011-11-18 22:22:14,ana...@wi... wrote:
>Hi,
> 
>In OCF-linux file cesa_ocf_drv.c, there is the following code in
>function mv_cesa_ocf_init() line 1179.
> 
>             cesa_device.plat_data = pdev->dev.platform_data;
> 
>I was not able to find where platform_data was set. I suppose it
>should've been done in Linux architecture files (specifically one of the
>files in /arch/arm/mach-kirkwood), probably where kirkwood_crypto_device
>is defined.
> 
>But I could not find it in code for kernel 2.6.31.8. In later version,
>i.e 3.1.1, this has been changed to refer orion_crypto structures.
>Again, can't find where platform_data is set for CESA.


This should be the platform_data register for CESA in 3.1.1:

plat-orion/common.c +945:

void __init orion_crypto_init(unsigned long mapbase,

                              unsigned long srambase,

                              unsigned long sram_size,

                              unsigned long irq)

{

        fill_resources(&orion_crypto, orion_crypto_resources,

                       mapbase, 0xffff, irq);

        orion_crypto.num_resources = 3;

        orion_crypto_resources[2].start = srambase;

        orion_crypto_resources[2].end = srambase + sram_size - 1;



        platform_device_register(&orion_crypto);

}







Best Regards,

Xufeng Zhang





>
>Could you please help me understand?
> 
>Regards
>Ananth
> 
>------------------------------------------------------------------------------
>All the data continuously generated in your IT infrastructure 
>contains a definitive record of customers, application performance, 
>security threats, fraudulent activity, and more. Splunk takes this 
>data and makes sense of it. IT sense. And common sense.
>http://p.sf.net/sfu/splunk-novd2d
>_______________________________________________
>Ocf-linux-users mailing list
>Ocf...@li...
>https://lists.sourceforge.net/lists/listinfo/ocf-linux-users

 

Re: [Ocf-linux-users] Marvell CESA: platform_data

[张绪峰 <sea...@12...>]

At 2011-11-18 22:22:14,ana...@wi... wrote:
>Hi,
>
>In OCF-linux file cesa_ocf_drv.c, there is the following code in
>function mv_cesa_ocf_init() line 1179.
>
>	cesa_device.plat_data = pdev->dev.platform_data;
>
>I was not able to find where platform_data was set. I suppose it
>should've been done in Linux architecture files (specifically one of the
>files in /arch/arm/mach-kirkwood), probably where kirkwood_crypto_device
>is defined.
>
>But I could not find it in code for kernel 2.6.31.8. In later version,
>i.e 3.1.1, this has been changed to refer orion_crypto structures.
>Again, can't find where platform_data is set for CESA.

This should be the platform_data register for CESA in 3.1.1:
plat-orion/common.c +945:
void __init orion_crypto_init(unsigned long mapbase,
                              unsigned long srambase,
                              unsigned long sram_size,
                              unsigned long irq)
{
        fill_resources(&orion_crypto, orion_crypto_resources,
                       mapbase, 0xffff, irq);
        orion_crypto.num_resources = 3;
        orion_crypto_resources[2].start = srambase;
        orion_crypto_resources[2].end = srambase + sram_size - 1;

        platform_device_register(&orion_crypto);
}



Best Regards,
Xufeng Zhang


>
>Could you please help me understand?
>
>Regards
>Ananth
>
>------------------------------------------------------------------------------
>All the data continuously generated in your IT infrastructure 
>contains a definitive record of customers, application performance, 
>security threats, fraudulent activity, and more. Splunk takes this 
>data and makes sense of it. IT sense. And common sense.
>http://p.sf.net/sfu/splunk-novd2d
>_______________________________________________
>Ocf-linux-users mailing list
>Ocf...@li...
>https://lists.sourceforge.net/lists/listinfo/ocf-linux-users

[Ocf-linux-users] Marvell CESA: platform_data

[<ana...@wi...>]

Hi,

In OCF-linux file cesa_ocf_drv.c, there is the following code in
function mv_cesa_ocf_init() line 1179.

	cesa_device.plat_data = pdev->dev.platform_data;

I was not able to find where platform_data was set. I suppose it
should've been done in Linux architecture files (specifically one of the
files in /arch/arm/mach-kirkwood), probably where kirkwood_crypto_device
is defined.

But I could not find it in code for kernel 2.6.31.8. In later version,
i.e 3.1.1, this has been changed to refer orion_crypto structures.
Again, can't find where platform_data is set for CESA.

Could you please help me understand?

Regards
Ananth

Re: [Ocf-linux-users] Segmentation fault

[Schuurman, H. <he...@ti...>]

Hi guys,

I'm running into an issue with the latest version of OCF. The test environment is a 2.6.37 kernel on an ARM Cortex-A8 with the 2011/07/20 release of OCF, using openssl 1.0.0e for testing.  Hardware crypto acceleration is not compiled into the kernel to eliminate any problems from that part of the code.

Without loading ocf/cryptodev/cryptosoft, I get the following expected result:

	root@dm816x-evm:~# /usr/local/ssl/bin/openssl dgst -sha1 -hmac etaonrishdlcupfm cryptotest
	HMAC-SHA1(cryptotest)= a4c468838e7fb7b59331f77bbd2d82baea489333

However, when I load ocf/cryptodev/cryptosoft, and execute the same command again, I get a segmentation fault.  Enabling debug on the cryptosoft driver and executing the same command again yields:

	root@dm816x-evm:~# modprobe ocf
	ocf: module license 'BSD' taints kernel.
	Disabling lock debugging due to kernel taint
	root@dm816x-evm:~# modprobe cryptodev
	root@dm816x-evm:~# modprobe cryptosoft swcr_debug=1
	cryptosoft_init(bf05ee64)
	cryptosoft_init:Algorithm 0 not supported
	cryptosoft_init:Algorithm Type 16 not supported (algorithm 3:'cbc(blowfish)')
	cryptosoft_init:Algorithm Type 16 not supported (algorithm 4:'cbc(cast5)')
	cryptosoft_init:Algorithm Type 16 not supported (algorithm 5:'cbc(skipjack)')
	cryptosoft_init:Algorithm Type 2 not supported (algorithm 8:'hmac(ripemd160)')
	cryptosoft_init:Algorithm Type 4 not supported (algorithm 9:'md5-kpdk')
	cryptosoft_init:Algorithm Type 4 not supported (algorithm 10:'sha1-kpdk')
	cryptosoft_init:Algorithm Type 16 not supported (algorithm 12:'ecb(arc4)')
	cryptosoft_init:Algorithm Type 2 not supported (algorithm 15:'hmac(digest_null)')
	cryptosoft_init:Algorithm Type 16 not supported (algorithm 16:'cbc(cipher_null)')
	cryptosoft_init:Algorithm Type 8 not supported (algorithm 17:'deflate')
	cryptosoft_init:Algorithm Type 2 not supported (algorithm 19:'hmac(sha384)')
	cryptosoft_init:Algorithm Type 2 not supported (algorithm 20:'hmac(sha512)')
	cryptosoft_init:Algorithm Type 16 not supported (algorithm 21:'cbc(camellia)')
	cryptosoft_init:Algorithm Type 4 not supported (algorithm 23:'sha384')
	cryptosoft_init:Algorithm Type 4 not supported (algorithm 24:'sha512')
	cryptosoft_init:Algorithm Type 4 not supported (algorithm 25:'ripemd160')
	root@dm816x-evm:~# /usr/local/ssl/bin/openssl dgst -sha1 -hmac etaonrishdlcupfm cryptotest
	swcr_newsession()
	swcr_newsession crypto_alloc_*blkcipher(cbc(des), 0x0)
	swcr_newsession cbc(des) cipher is async
	swcr_newsession key:cri->cri_klen=64,(cri->cri_klen + 7)/8=8
	    0x31 0x32 0x33 0x34 0x35 0x36 0x37 0x38
	swcr_freesession()
	swcr_newsession()
	swcr_newsession crypto_alloc_*blkcipher(cbc(des3_ede), 0x0)
	swcr_newsession cbc(des3_ede) cipher is async
	swcr_newsession key:cri->cri_klen=192,(cri->cri_klen + 7)/8=24
	    0x31 0x32 0x33 0x34 0x35 0x36 0x37 0x38
	    0x39 0x61 0x62 0x63 0x64 0x65 0x66 0x67
	    0x68 0x69 0x6a 0x6b 0x6c 0x6d 0x6e 0x6f
	swcr_freesession()
	swcr_newsession()
	swcr_newsession crypto_alloc_*blkcipher(cbc(aes), 0x0)
	swcr_newsession cbc(aes) cipher is async
	swcr_newsession key:cri->cri_klen=128,(cri->cri_klen + 7)/8=16
	    0x31 0x32 0x33 0x34 0x35 0x36 0x37 0x38
	    0x39 0x61 0x62 0x63 0x64 0x65 0x66 0x67
	swcr_freesession()
	swcr_newsession()
	swcr_newsession crypto_alloc_*blkcipher(cbc(aes), 0x0)
	swcr_newsession cbc(aes) cipher is async
	swcr_newsession key:cri->cri_klen=192,(cri->cri_klen + 7)/8=24
	    0x31 0x32 0x33 0x34 0x35 0x36 0x37 0x38
	    0x39 0x61 0x62 0x63 0x64 0x65 0x66 0x67
	    0x68 0x69 0x6a 0x6b 0x6c 0x6d 0x6e 0x6f
	swcr_freesession()
	swcr_newsession()
	swcr_newsession crypto_alloc_*blkcipher(cbc(aes), 0x0)
	swcr_newsession cbc(aes) cipher is async
	swcr_newsession key:cri->cri_klen=256,(cri->cri_klen + 7)/8=32
	    0x31 0x32 0x33 0x34 0x35 0x36 0x37 0x38
	    0x39 0x61 0x62 0x63 0x64 0x65 0x66 0x67
	    0x68 0x69 0x6a 0x6b 0x6c 0x6d 0x6e 0x6f
	    0x0 0x0 0x0 0x0 0x63 0x72 0x79 0x70
	swcr_freesession()
	swcr_newsession()
	swcr_newsession crypto_alloc_*hash(hmac(md5), 0x0)
	swcr_newsession hmac(md5) hash is async
	swcr_freesession()
	swcr_newsession()
	swcr_newsession crypto_alloc_*hash(hmac(sha1), 0x0)
	swcr_newsession hmac(sha1) hash is async
	swcr_freesession()
	swcr_newsession()
	swcr_newsession crypto_alloc_*hash(md5, 0x0)
	swcr_newsession md5 hash is async
	swcr_freesession()
	swcr_newsession()
	swcr_newsession crypto_alloc_*hash(sha1, 0x0)
	swcr_newsession sha1 hash is async
	swcr_freesession()
	swcr_newsession()
	swcr_newsession crypto_alloc_*hash(sha1, 0x0)
	swcr_newsession sha1 hash is async
	swcr_newsession()
	swcr_newsession crypto_alloc_*hash(sha1, 0x0)
	swcr_newsession sha1 hash is async
	swcr_freesession()
	swcr_freesession()
	Segmentation fault
	root@dm816x-evm:~#

Before I go any deeper into debugging, has anyone seen similar issues on other ports?

Regards,

Herman Schuurman

Re: [Ocf-linux-users] OCF for Marvell Kirkwood; probe function not called; does not init CESA

[David M. <dav...@mc...>]

Jivin ana...@wi... lays it down ...
> Hi David,
> 
> I'm using 2.6.31.8 kernel on Marvell Prestera platform.
> 
> The machine architecture chosen for the platform in /arch/arm is
> mach-feroceon-kw (/arch/arm/mach-feroceon-kw). I suppose this was
> provided by Marvell. Like in /arch/arm/Kirkwood/common.c where
> "mv_crypto" device is defined and registered, it is not done for
> mach-feroceon-kw. I copied the mv_crypto device from Kirkwood (not the
> best thing to do) and installed the mv_cesa.ko and mv_cesa_ocf_init()
> was called but also crashed. Have to figure out the correct device
> registers, sram and IRQ now.

Sounds like you are making progress.  Once you get the correct parameters in
there you should be looking much better :-)

Cheers,
Davidm


> -----Original Message-----
> From: David McCullough [mailto:dav...@mc...] 
> Sent: Wednesday, October 26, 2011 6:57 AM
> To: Anantharam V (WT01 - GMT-Telecom Equipment)
> Cc: ocf...@li...
> Subject: Re: [Ocf-linux-users] OCF for Marvell Kirkwood; probe function
> not called; does not init CESA
> 
> 
> Jivin ana...@wi... lays it down ...
> > Hi,
> > 
> > I'm trying to use OCF for Marvell's CESA. I have built ocf.ko,
> cryptodev.ko and mv_cesa.ko. I've used insmod to load them and all the
> loading works fine except for mv_cesa.ko. The function
> mv_cesa_ocf_init() does not get called. In the following code from OCF
> kirkwood's cesa_ocf_drv.c,
> > 
> > static struct platform_driver marvell_cesa = {
> >     .probe        = mv_cesa_ocf_init,
> >     .remove        = mv_cesa_ocf_exit,
> >     .driver        = {
> >         .owner    = THIS_MODULE,
> >         .name    = "mv_crypto",
> >     },
> > };
> > 
> > MODULE_ALIAS("platform:mv_crypto");
> > 
> > static int __init mv_cesa_init(void)
> > {
> >     return platform_driver_register(&marvell_cesa);
> > }
> > 
> > module_init(mv_cesa_init);
> > 
> > With insmod, the mv_cesa_init() is called but the debug in
> mv_cesa_ocf_init() is not printed. Is platform_driver_register()
> internally supposed to call the .probe function? Or when is the probe
> function supposed to be called? What can be done to call the probe
> function of marvell_cesa?
> 
> I am not sure,  what kernel version are you using and what platform are
> you
> building for ?
> 
> Have you created a custom platform of your own ?
> 
> I had a look at our marvel based platform where I know this was working
> (haven't used it for quite a while) and it all looks similar.
> 
> You may just need to work though the platform driver code until you
> figure
> out why it isn't called :-(
> 
> Cheers,
> Davidm
> 
> -- 
> David McCullough,      dav...@mc...,  Ph:+61 734352815
> McAfee - SnapGear      http://www.mcafee.com
> http://www.uCdot.org
> 
> Please do not print this email unless it is absolutely necessary. 
> 
> The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. 
> 
> WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. 
> 
> www.wipro.com
> 
> 

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

Re: [Ocf-linux-users] OCF for Marvell Kirkwood; probe function not called; does not init CESA

[<ana...@wi...>]

Hi David,

I'm using 2.6.31.8 kernel on Marvell Prestera platform.

The machine architecture chosen for the platform in /arch/arm is
mach-feroceon-kw (/arch/arm/mach-feroceon-kw). I suppose this was
provided by Marvell. Like in /arch/arm/Kirkwood/common.c where
"mv_crypto" device is defined and registered, it is not done for
mach-feroceon-kw. I copied the mv_crypto device from Kirkwood (not the
best thing to do) and installed the mv_cesa.ko and mv_cesa_ocf_init()
was called but also crashed. Have to figure out the correct device
registers, sram and IRQ now.

Thanks
Ananth

-----Original Message-----
From: David McCullough [mailto:dav...@mc...] 
Sent: Wednesday, October 26, 2011 6:57 AM
To: Anantharam V (WT01 - GMT-Telecom Equipment)
Cc: ocf...@li...
Subject: Re: [Ocf-linux-users] OCF for Marvell Kirkwood; probe function
not called; does not init CESA


Jivin ana...@wi... lays it down ...
> Hi,
> 
> I'm trying to use OCF for Marvell's CESA. I have built ocf.ko,
cryptodev.ko and mv_cesa.ko. I've used insmod to load them and all the
loading works fine except for mv_cesa.ko. The function
mv_cesa_ocf_init() does not get called. In the following code from OCF
kirkwood's cesa_ocf_drv.c,
> 
> static struct platform_driver marvell_cesa = {
>     .probe        = mv_cesa_ocf_init,
>     .remove        = mv_cesa_ocf_exit,
>     .driver        = {
>         .owner    = THIS_MODULE,
>         .name    = "mv_crypto",
>     },
> };
> 
> MODULE_ALIAS("platform:mv_crypto");
> 
> static int __init mv_cesa_init(void)
> {
>     return platform_driver_register(&marvell_cesa);
> }
> 
> module_init(mv_cesa_init);
> 
> With insmod, the mv_cesa_init() is called but the debug in
mv_cesa_ocf_init() is not printed. Is platform_driver_register()
internally supposed to call the .probe function? Or when is the probe
function supposed to be called? What can be done to call the probe
function of marvell_cesa?

I am not sure,  what kernel version are you using and what platform are
you
building for ?

Have you created a custom platform of your own ?

I had a look at our marvel based platform where I know this was working
(haven't used it for quite a while) and it all looks similar.

You may just need to work though the platform driver code until you
figure
out why it isn't called :-(

Cheers,
Davidm

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

Re: [Ocf-linux-users] OCF for Marvell Kirkwood; probe function not called; does not init CESA

[David M. <dav...@mc...>]

Jivin ana...@wi... lays it down ...
> Hi,
> 
> I'm trying to use OCF for Marvell's CESA. I have built ocf.ko, cryptodev.ko and mv_cesa.ko. I've used insmod to load them and all the loading works fine except for mv_cesa.ko. The function mv_cesa_ocf_init() does not get called. In the following code from OCF kirkwood's cesa_ocf_drv.c,
> 
> static struct platform_driver marvell_cesa = {
>     .probe        = mv_cesa_ocf_init,
>     .remove        = mv_cesa_ocf_exit,
>     .driver        = {
>         .owner    = THIS_MODULE,
>         .name    = "mv_crypto",
>     },
> };
> 
> MODULE_ALIAS("platform:mv_crypto");
> 
> static int __init mv_cesa_init(void)
> {
>     return platform_driver_register(&marvell_cesa);
> }
> 
> module_init(mv_cesa_init);
> 
> With insmod, the mv_cesa_init() is called but the debug in mv_cesa_ocf_init() is not printed. Is platform_driver_register() internally supposed to call the .probe function? Or when is the probe function supposed to be called? What can be done to call the probe function of marvell_cesa?

I am not sure,  what kernel version are you using and what platform are you
building for ?

Have you created a custom platform of your own ?

I had a look at our marvel based platform where I know this was working
(haven't used it for quite a while) and it all looks similar.

You may just need to work though the platform driver code until you figure
out why it isn't called :-(

Cheers,
Davidm

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

[Ocf-linux-users] OCF for Marvell Kirkwood; probe function not called; does not init CESA

[<ana...@wi...>]

Hi,

I'm trying to use OCF for Marvell's CESA. I have built ocf.ko,
cryptodev.ko and mv_cesa.ko. I've used insmod to load them and all the
loading works fine except for mv_cesa.ko. The function
mv_cesa_ocf_init() does not get called. In the following code from OCF
kirkwood's cesa_ocf_drv.c,

static struct platform_driver marvell_cesa = {
    .probe        = mv_cesa_ocf_init,
    .remove        = mv_cesa_ocf_exit,
    .driver        = {
        .owner    = THIS_MODULE,
        .name    = "mv_crypto",
    },
};

MODULE_ALIAS("platform:mv_crypto");

static int __init mv_cesa_init(void)
{
    return platform_driver_register(&marvell_cesa);
}

module_init(mv_cesa_init);

With insmod, the mv_cesa_init() is called but the debug in
mv_cesa_ocf_init() is not printed. Is platform_driver_register()
internally supposed to call the .probe function? Or when is the probe
function supposed to be called? What can be done to call the probe
function of marvell_cesa?

Thanks
Ananth

Re: [Ocf-linux-users] Run cryptotest for md5 alg on talitos h/w driver lead to kernel Oops or generate error interrupt

[David M. <dav...@mc...>]

Jivin 张绪峰 lays it down ...
> 
> 
> 
> 
> ? 2011-10-12 11:53:37,"David McCullough" <dav...@mc...> ??:
> >
> >Jivin ??? lays it down ...
> >> After run some tests and have a investigation, I found the generated error interrupt
> >> have relationship with the length of the descriptor pointer entry, here is the relative codes:
> >> ---------------------------------------------------------------------------------------------------------------
> >> } else if (crp->crp_flags & CRYPTO_F_IOV) {
> >>                 /* using IOV buffers */
> >>                 struct uio *uiop = (struct uio *)crp->crp_buf;
> >>                 if (uiop->uio_iovcnt > 1) {
> >>                         printk("%s: iov frags unimplemented\n",
> >>                                         device_get_nameunit(sc->sc_cdev));
> >>                         err = EINVAL;
> >>                         goto errout;
> >>                 }
> >>                 td->ptr[in_fifo].ptr = dma_map_single(device,
> >>                         uiop->uio_iov->iov_base, crp->crp_ilen, DMA_TO_DEVICE);
> >>                 td->ptr[in_fifo].len = crp->crp_ilen;
> >>                 /* crp_olen is never set; always use crp_ilen */
> >>                 td->ptr[out_fifo].ptr = dma_map_single(device,
> >>                         uiop->uio_iov->iov_base,
> >>                         crp->crp_ilen, DMA_TO_DEVICE);
> >>                 td->ptr[out_fifo].len = crp->crp_ilen;  
> >>         } else {
> >>                 /* using contig buffers */
> >> ------------------------------------------------------------------------------------------------------
> >> If I change "td->ptr[in_fifo].len = crp->crp_ilen;" to "td->ptr[in_fifo].len = 32;" and 
> >> change "td->ptr[out_fifo].len = crp->crp_ilen; " to "td->ptr[out_fifo].len = 32", then I can
> >> run "./cryptotest -va md5 1 1024" successfully without any error interrupt, but surly it's
> >> not correct.
> >
> >Kim's the best person to help you on this one I think.  Hopefully he's
> >kicking around somewhere :-)
> >
> >What was the value of crp->crp_ilen before you changed it to 32 ?
> Thanks for your reply, David.
> 
> The value of crp->crp_ilen depends on what I set for the number of bytes of text to encrypt,
> eg. if I run "./cryptotest -va md5 1 1024", then crp->crp_ilen is 1024.

Ok,  that makes sense.

Not sure why this would be causing the HW/driver to get upset,  hopefully
someone who knows the chip can comment :-)

Its interesting that the drivers is mapping the same address for
INPUT/OUTPUT (uiop->uio_iov->iov_base) when it could do it once as a
DMA_BIDIRECTIONAL ?  I don't think it would matter myself,  but it might be
something to look at ?

Cheers,
Davidm

> >Cheers,
> >Davidm
> >
> >
> >> At 2011-10-10 16:03:49,"???" <sea...@12...> wrote:
> >> 
> >> 
> >> 	 Hi experts,
> >> 	
> >> 	I meet a problem when run cryptotest for md5 alg on talitos h/w driver.
> >> 	Board: Freescale mpc8572ds board
> >> 	OS: linux-2.6.34
> >> 	
> >> 	Reproduce steps:
> >> 	1. # mknod /dev/crypto c 10 70
> >> 	2. # insmod ocf.ko
> >> 	3. # insmod cryptodev.ko
> >> 	4. # insmod talitos.ko
> >> 	5. #  ./cryptotest -va md5 1 1024
> >> 	crid = 3000000
> >> 	alg = md5
> >> 	session = 0x0
> >> 	device = talitos0
> >> 	count = 1, size = 1024
> >> 	cleartext:
> >> 	0000: 38 21 33 74 73 31 21 75 68 37 36 68 33 74 30 75
> >> 	0010: 32 75 32 31 61 74 73 69 39 65 38 30 69 61 6f 6a
> >> 	cryptotest: line 465:ioctl(CIOCCRYPT): Input/output error
> >> 	6. # dmesg
> >> 	talitos0: got error interrupt - ISR 0x00000002_00000200
> >> 	7. # ./cryptotest -va md5 1 64
> >> 	Unable to handle kernel paging request for data at address 0x00000004
> >> 	Faulting instruction address: 0xc00d18fc
> >> 	Oops: Kernel access of bad area, sig: 11 [#1]
> >> 	PREEMPT 8 68 38 65 33 73SMP NR_CPUS=2  LTT NESTING LEVEL : 0
> >> 	MPC8572 DS
> >> 	NIP [c00d18fc] vma_prio_tree_remove+0x118/0x130
> >> 	LR [c00de52c] __remove_shared_vm_struct+0x60/0x90
> >> 	Call Trace:
> >> 	[ef115de0] [c141c0b8] 0xc141c0b8 (unreliable)
> >> 	[ef115e00] [c00de52c] __remove_shared_vm_struct+0x60/0x90
> >> 	[ef115e10] [c00de59c] unlink_file_vma+0x40/0x5c
> >> 	[ef115e30] [c00dbde8] free_pgtables+0x60/0xbc
> >> 	[ef115e50] [c00de238] exit_mmap+0x124/0x1b4
> >> 	[ef115e80] [c0044c1c] mmput+0x58/0x120
> >> 	[ef115e90] [c0049948] exit_mm+0x148/0x168
> >> 	[ef115ec0] [c004baac] do_exit+0x5d8/0x6b0
> >> 	[ef115f10] [c004bbcc] do_group_exit+0x48/0xa8
> >> 	[ef115f30] [c004bc40] sys_exit_group+0x14/0x28
> >> 	[ef115f40] [c0010ef0] ret_from_syscall+0x0/0x4
> >> 	--- Exception: c01 at 0xfef56c0
> >> 	    LR = 0xfef5690
> >> 	Instruction dump:
> >> 	3949ffd4 91280000 91090004 900b002c 915f0038 900b0030 93ea0038 4bffff8c 
> >> 	814b0030 380b002c 812b002c 912a0000 <91490004> 900b002c 900b0030 4bffff6c 
> >> 	---[ end trace 11d846f2058aa86c ]---
> >> 	Fixing recursive fault but reboot is needed!
> >> 	BUG: scheduling while atomic: cryptotest/138/0x00000003
> >> 	Modules linked in: ocf(P) cryptodev(P) talitos
> >> 	Call Trace:
> >> 	[ef115bd0] [c0007a04] show_stack+0x44/0x160 (unreliable)
> >> 	[ef115c00] [c00392f0] __schedule_bug+0x80/0x84
> >> 	[ef115c10] [c0541ba0] schedule+0x460/0x638
> >> 	[ef115c90] [c004bb00] do_exit+0x62c/0x6b0
> >> 	[ef115ce0] [c000dfa4] die+0xf0/0x224
> >> 	[ef115d10] [c001523c] bad_page_fault+0x90/0xc8
> >> 	[ef115d20] [c00113a8] handle_page_fault+0x7c/0x80
> >> 	--- Exception: 300 at vma_prio_tree_remove+0x118/0x130
> >> 	    LR = __remove_shared_vm_struct+0x60/0x90
> >> 	[ef115de0] [c141c0b8] 0xc141c0b8 (unreliable)
> >> 	[ef115e00] [c00de52c] __remove_shared_vm_struct+0x60/0x90
> >> 	[ef115e10] [c00de59c] unlink_file_vma+0x40/0x5c
> >> 	
> >> 	
> >> 	The interrupt error is MDEU AE (address error), but it's really difficult for me to trace the root cause.
> >> 	I'm not sure why the kernel Oops happens when tried 64 sizes, and it was not always happens, I suspect
> >> 	it was caused by the same reason with error interrupt.
> >> 	Moreover, it's ok to run "./cryptotest -va md5 1 8".
> >> 	Please help me, thanks in advance!
> >> 	
> >> 	
> >> 	
> >> 	
> >> 	Thanks,
> >> 	Xufeng Zhang
> >> 	
> >> 
> >> 
> >> 	
> >> 
> >> 
> >> 
> >
> >-- 
> >David McCullough,      dav...@mc...,  Ph:+61 734352815
> >McAfee - SnapGear      http://www.mcafee.com         http://www.uCdot.org
> 
> 
> 
> 

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

Re: [Ocf-linux-users] Run cryptotest for md5 alg on talitos h/w driver lead to kernel Oops or generate error interrupt

[张绪峰 <sea...@12...>]

在 2011-10-12 11:53:37，"David McCullough" <dav...@mc...> 写道：
>
>Jivin 张绪峰 lays it down ...
>> After run some tests and have a investigation, I found the generated error interrupt
>> have relationship with the length of the descriptor pointer entry, here is the relative codes:
>> ---------------------------------------------------------------------------------------------------------------
>> } else if (crp->crp_flags & CRYPTO_F_IOV) {
>>                 /* using IOV buffers */
>>                 struct uio *uiop = (struct uio *)crp->crp_buf;
>>                 if (uiop->uio_iovcnt > 1) {
>>                         printk("%s: iov frags unimplemented\n",
>>                                         device_get_nameunit(sc->sc_cdev));
>>                         err = EINVAL;
>>                         goto errout;
>>                 }
>>                 td->ptr[in_fifo].ptr = dma_map_single(device,
>>                         uiop->uio_iov->iov_base, crp->crp_ilen, DMA_TO_DEVICE);
>>                 td->ptr[in_fifo].len = crp->crp_ilen;
>>                 /* crp_olen is never set; always use crp_ilen */
>>                 td->ptr[out_fifo].ptr = dma_map_single(device,
>>                         uiop->uio_iov->iov_base,
>>                         crp->crp_ilen, DMA_TO_DEVICE);
>>                 td->ptr[out_fifo].len = crp->crp_ilen;  
>>         } else {
>>                 /* using contig buffers */
>> ------------------------------------------------------------------------------------------------------
>> If I change "td->ptr[in_fifo].len = crp->crp_ilen;" to "td->ptr[in_fifo].len = 32;" and 
>> change "td->ptr[out_fifo].len = crp->crp_ilen; " to "td->ptr[out_fifo].len = 32", then I can
>> run "./cryptotest -va md5 1 1024" successfully without any error interrupt, but surly it's
>> not correct.
>
>Kim's the best person to help you on this one I think.  Hopefully he's
>kicking around somewhere :-)
>
>What was the value of crp->crp_ilen before you changed it to 32 ?
Thanks for your reply, David.

The value of crp->crp_ilen depends on what I set for the number of bytes of text to encrypt,
eg. if I run "./cryptotest -va md5 1 1024", then crp->crp_ilen is 1024.



Thanks,
Xufeng Zhang

>
>Cheers,
>Davidm
>
>
>> At 2011-10-10 16:03:49,"???" <sea...@12...> wrote:
>> 
>> 
>> 	 Hi experts,
>> 	
>> 	I meet a problem when run cryptotest for md5 alg on talitos h/w driver.
>> 	Board: Freescale mpc8572ds board
>> 	OS: linux-2.6.34
>> 	
>> 	Reproduce steps:
>> 	1. # mknod /dev/crypto c 10 70
>> 	2. # insmod ocf.ko
>> 	3. # insmod cryptodev.ko
>> 	4. # insmod talitos.ko
>> 	5. #  ./cryptotest -va md5 1 1024
>> 	crid = 3000000
>> 	alg = md5
>> 	session = 0x0
>> 	device = talitos0
>> 	count = 1, size = 1024
>> 	cleartext:
>> 	0000: 38 21 33 74 73 31 21 75 68 37 36 68 33 74 30 75
>> 	0010: 32 75 32 31 61 74 73 69 39 65 38 30 69 61 6f 6a
>> 	cryptotest: line 465:ioctl(CIOCCRYPT): Input/output error
>> 	6. # dmesg
>> 	talitos0: got error interrupt - ISR 0x00000002_00000200
>> 	7. # ./cryptotest -va md5 1 64
>> 	Unable to handle kernel paging request for data at address 0x00000004
>> 	Faulting instruction address: 0xc00d18fc
>> 	Oops: Kernel access of bad area, sig: 11 [#1]
>> 	PREEMPT 8 68 38 65 33 73SMP NR_CPUS=2  LTT NESTING LEVEL : 0
>> 	MPC8572 DS
>> 	NIP [c00d18fc] vma_prio_tree_remove+0x118/0x130
>> 	LR [c00de52c] __remove_shared_vm_struct+0x60/0x90
>> 	Call Trace:
>> 	[ef115de0] [c141c0b8] 0xc141c0b8 (unreliable)
>> 	[ef115e00] [c00de52c] __remove_shared_vm_struct+0x60/0x90
>> 	[ef115e10] [c00de59c] unlink_file_vma+0x40/0x5c
>> 	[ef115e30] [c00dbde8] free_pgtables+0x60/0xbc
>> 	[ef115e50] [c00de238] exit_mmap+0x124/0x1b4
>> 	[ef115e80] [c0044c1c] mmput+0x58/0x120
>> 	[ef115e90] [c0049948] exit_mm+0x148/0x168
>> 	[ef115ec0] [c004baac] do_exit+0x5d8/0x6b0
>> 	[ef115f10] [c004bbcc] do_group_exit+0x48/0xa8
>> 	[ef115f30] [c004bc40] sys_exit_group+0x14/0x28
>> 	[ef115f40] [c0010ef0] ret_from_syscall+0x0/0x4
>> 	--- Exception: c01 at 0xfef56c0
>> 	    LR = 0xfef5690
>> 	Instruction dump:
>> 	3949ffd4 91280000 91090004 900b002c 915f0038 900b0030 93ea0038 4bffff8c 
>> 	814b0030 380b002c 812b002c 912a0000 <91490004> 900b002c 900b0030 4bffff6c 
>> 	---[ end trace 11d846f2058aa86c ]---
>> 	Fixing recursive fault but reboot is needed!
>> 	BUG: scheduling while atomic: cryptotest/138/0x00000003
>> 	Modules linked in: ocf(P) cryptodev(P) talitos
>> 	Call Trace:
>> 	[ef115bd0] [c0007a04] show_stack+0x44/0x160 (unreliable)
>> 	[ef115c00] [c00392f0] __schedule_bug+0x80/0x84
>> 	[ef115c10] [c0541ba0] schedule+0x460/0x638
>> 	[ef115c90] [c004bb00] do_exit+0x62c/0x6b0
>> 	[ef115ce0] [c000dfa4] die+0xf0/0x224
>> 	[ef115d10] [c001523c] bad_page_fault+0x90/0xc8
>> 	[ef115d20] [c00113a8] handle_page_fault+0x7c/0x80
>> 	--- Exception: 300 at vma_prio_tree_remove+0x118/0x130
>> 	    LR = __remove_shared_vm_struct+0x60/0x90
>> 	[ef115de0] [c141c0b8] 0xc141c0b8 (unreliable)
>> 	[ef115e00] [c00de52c] __remove_shared_vm_struct+0x60/0x90
>> 	[ef115e10] [c00de59c] unlink_file_vma+0x40/0x5c
>> 	
>> 	
>> 	The interrupt error is MDEU AE (address error), but it's really difficult for me to trace the root cause.
>> 	I'm not sure why the kernel Oops happens when tried 64 sizes, and it was not always happens, I suspect
>> 	it was caused by the same reason with error interrupt.
>> 	Moreover, it's ok to run "./cryptotest -va md5 1 8".
>> 	Please help me, thanks in advance!
>> 	
>> 	
>> 	
>> 	
>> 	Thanks,
>> 	Xufeng Zhang
>> 	
>> 
>> 
>> 	
>> 
>> 
>> 
>
>-- 
>David McCullough,      dav...@mc...,  Ph:+61 734352815
>McAfee - SnapGear      http://www.mcafee.com         http://www.uCdot.org

Re: [Ocf-linux-users] Run cryptotest for md5 alg on talitos h/w driver lead to kernel Oops or generate error interrupt

[David M. <dav...@mc...>]

Jivin 张绪峰 lays it down ...
> After run some tests and have a investigation, I found the generated error interrupt
> have relationship with the length of the descriptor pointer entry, here is the relative codes:
> ---------------------------------------------------------------------------------------------------------------
> } else if (crp->crp_flags & CRYPTO_F_IOV) {
>                 /* using IOV buffers */
>                 struct uio *uiop = (struct uio *)crp->crp_buf;
>                 if (uiop->uio_iovcnt > 1) {
>                         printk("%s: iov frags unimplemented\n",
>                                         device_get_nameunit(sc->sc_cdev));
>                         err = EINVAL;
>                         goto errout;
>                 }
>                 td->ptr[in_fifo].ptr = dma_map_single(device,
>                         uiop->uio_iov->iov_base, crp->crp_ilen, DMA_TO_DEVICE);
>                 td->ptr[in_fifo].len = crp->crp_ilen;
>                 /* crp_olen is never set; always use crp_ilen */
>                 td->ptr[out_fifo].ptr = dma_map_single(device,
>                         uiop->uio_iov->iov_base,
>                         crp->crp_ilen, DMA_TO_DEVICE);
>                 td->ptr[out_fifo].len = crp->crp_ilen;  
>         } else {
>                 /* using contig buffers */
> ------------------------------------------------------------------------------------------------------
> If I change "td->ptr[in_fifo].len = crp->crp_ilen;" to "td->ptr[in_fifo].len = 32;" and 
> change "td->ptr[out_fifo].len = crp->crp_ilen; " to "td->ptr[out_fifo].len = 32", then I can
> run "./cryptotest -va md5 1 1024" successfully without any error interrupt, but surly it's
> not correct.

Kim's the best person to help you on this one I think.  Hopefully he's
kicking around somewhere :-)

What was the value of crp->crp_ilen before you changed it to 32 ?

Cheers,
Davidm


> At 2011-10-10 16:03:49,"???" <sea...@12...> wrote:
> 
> 
> 	 Hi experts,
> 	
> 	I meet a problem when run cryptotest for md5 alg on talitos h/w driver.
> 	Board: Freescale mpc8572ds board
> 	OS: linux-2.6.34
> 	
> 	Reproduce steps:
> 	1. # mknod /dev/crypto c 10 70
> 	2. # insmod ocf.ko
> 	3. # insmod cryptodev.ko
> 	4. # insmod talitos.ko
> 	5. #  ./cryptotest -va md5 1 1024
> 	crid = 3000000
> 	alg = md5
> 	session = 0x0
> 	device = talitos0
> 	count = 1, size = 1024
> 	cleartext:
> 	0000: 38 21 33 74 73 31 21 75 68 37 36 68 33 74 30 75
> 	0010: 32 75 32 31 61 74 73 69 39 65 38 30 69 61 6f 6a
> 	cryptotest: line 465:ioctl(CIOCCRYPT): Input/output error
> 	6. # dmesg
> 	talitos0: got error interrupt - ISR 0x00000002_00000200
> 	7. # ./cryptotest -va md5 1 64
> 	Unable to handle kernel paging request for data at address 0x00000004
> 	Faulting instruction address: 0xc00d18fc
> 	Oops: Kernel access of bad area, sig: 11 [#1]
> 	PREEMPT 8 68 38 65 33 73SMP NR_CPUS=2  LTT NESTING LEVEL : 0
> 	MPC8572 DS
> 	NIP [c00d18fc] vma_prio_tree_remove+0x118/0x130
> 	LR [c00de52c] __remove_shared_vm_struct+0x60/0x90
> 	Call Trace:
> 	[ef115de0] [c141c0b8] 0xc141c0b8 (unreliable)
> 	[ef115e00] [c00de52c] __remove_shared_vm_struct+0x60/0x90
> 	[ef115e10] [c00de59c] unlink_file_vma+0x40/0x5c
> 	[ef115e30] [c00dbde8] free_pgtables+0x60/0xbc
> 	[ef115e50] [c00de238] exit_mmap+0x124/0x1b4
> 	[ef115e80] [c0044c1c] mmput+0x58/0x120
> 	[ef115e90] [c0049948] exit_mm+0x148/0x168
> 	[ef115ec0] [c004baac] do_exit+0x5d8/0x6b0
> 	[ef115f10] [c004bbcc] do_group_exit+0x48/0xa8
> 	[ef115f30] [c004bc40] sys_exit_group+0x14/0x28
> 	[ef115f40] [c0010ef0] ret_from_syscall+0x0/0x4
> 	--- Exception: c01 at 0xfef56c0
> 	    LR = 0xfef5690
> 	Instruction dump:
> 	3949ffd4 91280000 91090004 900b002c 915f0038 900b0030 93ea0038 4bffff8c 
> 	814b0030 380b002c 812b002c 912a0000 <91490004> 900b002c 900b0030 4bffff6c 
> 	---[ end trace 11d846f2058aa86c ]---
> 	Fixing recursive fault but reboot is needed!
> 	BUG: scheduling while atomic: cryptotest/138/0x00000003
> 	Modules linked in: ocf(P) cryptodev(P) talitos
> 	Call Trace:
> 	[ef115bd0] [c0007a04] show_stack+0x44/0x160 (unreliable)
> 	[ef115c00] [c00392f0] __schedule_bug+0x80/0x84
> 	[ef115c10] [c0541ba0] schedule+0x460/0x638
> 	[ef115c90] [c004bb00] do_exit+0x62c/0x6b0
> 	[ef115ce0] [c000dfa4] die+0xf0/0x224
> 	[ef115d10] [c001523c] bad_page_fault+0x90/0xc8
> 	[ef115d20] [c00113a8] handle_page_fault+0x7c/0x80
> 	--- Exception: 300 at vma_prio_tree_remove+0x118/0x130
> 	    LR = __remove_shared_vm_struct+0x60/0x90
> 	[ef115de0] [c141c0b8] 0xc141c0b8 (unreliable)
> 	[ef115e00] [c00de52c] __remove_shared_vm_struct+0x60/0x90
> 	[ef115e10] [c00de59c] unlink_file_vma+0x40/0x5c
> 	
> 	
> 	The interrupt error is MDEU AE (address error), but it's really difficult for me to trace the root cause.
> 	I'm not sure why the kernel Oops happens when tried 64 sizes, and it was not always happens, I suspect
> 	it was caused by the same reason with error interrupt.
> 	Moreover, it's ok to run "./cryptotest -va md5 1 8".
> 	Please help me, thanks in advance!
> 	
> 	
> 	
> 	
> 	Thanks,
> 	Xufeng Zhang
> 	
> 
> 
> 	
> 
> 
> 

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

Re: [Ocf-linux-users] Run cryptotest for md5 alg on talitos h/w driver lead to kernel Oops or generate error interrupt

[张绪峰 <sea...@12...>]

After run some tests and have a investigation, I found the generated error interrupt
have relationship with the length of the descriptor pointer entry, here is the relative codes:
---------------------------------------------------------------------------------------------------------------
} else if (crp->crp_flags & CRYPTO_F_IOV) {
                /* using IOV buffers */
                struct uio *uiop = (struct uio *)crp->crp_buf;
                if (uiop->uio_iovcnt > 1) {
                        printk("%s: iov frags unimplemented\n",
                                        device_get_nameunit(sc->sc_cdev));
                        err = EINVAL;
                        goto errout;
                }
                td->ptr[in_fifo].ptr = dma_map_single(device,
                        uiop->uio_iov->iov_base, crp->crp_ilen, DMA_TO_DEVICE);
                td->ptr[in_fifo].len = crp->crp_ilen;
                /* crp_olen is never set; always use crp_ilen */
                td->ptr[out_fifo].ptr = dma_map_single(device,
                        uiop->uio_iov->iov_base,
                        crp->crp_ilen, DMA_TO_DEVICE);
                td->ptr[out_fifo].len = crp->crp_ilen; 
        } else {
                /* using contig buffers */
------------------------------------------------------------------------------------------------------
If I change "td->ptr[in_fifo].len = crp->crp_ilen;" to "td->ptr[in_fifo].len = 32;" and
change "td->ptr[out_fifo].len = crp->crp_ilen; " to "td->ptr[out_fifo].len = 32", then I can
run "./cryptotest -va md5 1 1024" successfully without any error interrupt, but surly it's
not correct.


Thanks,
Xufeng Zhang



At 2011-10-10 16:03:49,"张绪峰" <sea...@12...> wrote:

 Hi experts,

I meet a problem when run cryptotest for md5 alg on talitos h/w driver.
Board: Freescale mpc8572ds board
OS: linux-2.6.34

Reproduce steps:
1. # mknod /dev/crypto c 10 70
2. # insmod ocf.ko
3. # insmod cryptodev.ko
4. # insmod talitos.ko
5. #  ./cryptotest -va md5 1 1024
crid = 3000000
alg = md5
session = 0x0
device = talitos0
count = 1, size = 1024
cleartext:
0000: 38 21 33 74 73 31 21 75 68 37 36 68 33 74 30 75
0010: 32 75 32 31 61 74 73 69 39 65 38 30 69 61 6f 6a
cryptotest: line 465:ioctl(CIOCCRYPT): Input/output error
6. # dmesg
talitos0: got error interrupt - ISR 0x00000002_00000200
7. # ./cryptotest -va md5 1 64
Unable to handle kernel paging request for data at address 0x00000004
Faulting instruction address: 0xc00d18fc
Oops: Kernel access of bad area, sig: 11 [#1]
PREEMPT 8 68 38 65 33 73SMP NR_CPUS=2  LTT NESTING LEVEL : 0
MPC8572 DS
NIP [c00d18fc] vma_prio_tree_remove+0x118/0x130
LR [c00de52c] __remove_shared_vm_struct+0x60/0x90
Call Trace:
[ef115de0] [c141c0b8] 0xc141c0b8 (unreliable)
[ef115e00] [c00de52c] __remove_shared_vm_struct+0x60/0x90
[ef115e10] [c00de59c] unlink_file_vma+0x40/0x5c
[ef115e30] [c00dbde8] free_pgtables+0x60/0xbc
[ef115e50] [c00de238] exit_mmap+0x124/0x1b4
[ef115e80] [c0044c1c] mmput+0x58/0x120
[ef115e90] [c0049948] exit_mm+0x148/0x168
[ef115ec0] [c004baac] do_exit+0x5d8/0x6b0
[ef115f10] [c004bbcc] do_group_exit+0x48/0xa8
[ef115f30] [c004bc40] sys_exit_group+0x14/0x28
[ef115f40] [c0010ef0] ret_from_syscall+0x0/0x4
--- Exception: c01 at 0xfef56c0
    LR = 0xfef5690
Instruction dump:
3949ffd4 91280000 91090004 900b002c 915f0038 900b0030 93ea0038 4bffff8c
814b0030 380b002c 812b002c 912a0000 <91490004> 900b002c 900b0030 4bffff6c
---[ end trace 11d846f2058aa86c ]---
Fixing recursive fault but reboot is needed!
BUG: scheduling while atomic: cryptotest/138/0x00000003
Modules linked in: ocf(P) cryptodev(P) talitos
Call Trace:
[ef115bd0] [c0007a04] show_stack+0x44/0x160 (unreliable)
[ef115c00] [c00392f0] __schedule_bug+0x80/0x84
[ef115c10] [c0541ba0] schedule+0x460/0x638
[ef115c90] [c004bb00] do_exit+0x62c/0x6b0
[ef115ce0] [c000dfa4] die+0xf0/0x224
[ef115d10] [c001523c] bad_page_fault+0x90/0xc8
[ef115d20] [c00113a8] handle_page_fault+0x7c/0x80
--- Exception: 300 at vma_prio_tree_remove+0x118/0x130
    LR = __remove_shared_vm_struct+0x60/0x90
[ef115de0] [c141c0b8] 0xc141c0b8 (unreliable)
[ef115e00] [c00de52c] __remove_shared_vm_struct+0x60/0x90
[ef115e10] [c00de59c] unlink_file_vma+0x40/0x5c


The interrupt error is MDEU AE (address error), but it's really difficult for me to trace the root cause.
I'm not sure why the kernel Oops happens when tried 64 sizes, and it was not always happens, I suspect
it was caused by the same reason with error interrupt.
Moreover, it's ok to run "./cryptotest -va md5 1 8".
Please help me, thanks in advance!




Thanks,
Xufeng Zhang

[Ocf-linux-users] Run cryptotest for md5 alg on talitos h/w driver lead to kernel Oops or generate error interrupt

[张绪峰 <sea...@12...>]

 Hi experts,

I meet a problem when run cryptotest for md5 alg on talitos h/w driver.
Board: Freescale mpc8572ds board
OS: linux-2.6.34

Reproduce steps:
1. # mknod /dev/crypto c 10 70
2. # insmod ocf.ko
3. # insmod cryptodev.ko
4. # insmod talitos.ko
5. #  ./cryptotest -va md5 1 1024
crid = 3000000
alg = md5
session = 0x0
device = talitos0
count = 1, size = 1024
cleartext:
0000: 38 21 33 74 73 31 21 75 68 37 36 68 33 74 30 75
0010: 32 75 32 31 61 74 73 69 39 65 38 30 69 61 6f 6a
cryptotest: line 465:ioctl(CIOCCRYPT): Input/output error
6. # dmesg
talitos0: got error interrupt - ISR 0x00000002_00000200
7. # ./cryptotest -va md5 1 64
Unable to handle kernel paging request for data at address 0x00000004
Faulting instruction address: 0xc00d18fc
Oops: Kernel access of bad area, sig: 11 [#1]
PREEMPT 8 68 38 65 33 73SMP NR_CPUS=2  LTT NESTING LEVEL : 0
MPC8572 DS
NIP [c00d18fc] vma_prio_tree_remove+0x118/0x130
LR [c00de52c] __remove_shared_vm_struct+0x60/0x90
Call Trace:
[ef115de0] [c141c0b8] 0xc141c0b8 (unreliable)
[ef115e00] [c00de52c] __remove_shared_vm_struct+0x60/0x90
[ef115e10] [c00de59c] unlink_file_vma+0x40/0x5c
[ef115e30] [c00dbde8] free_pgtables+0x60/0xbc
[ef115e50] [c00de238] exit_mmap+0x124/0x1b4
[ef115e80] [c0044c1c] mmput+0x58/0x120
[ef115e90] [c0049948] exit_mm+0x148/0x168
[ef115ec0] [c004baac] do_exit+0x5d8/0x6b0
[ef115f10] [c004bbcc] do_group_exit+0x48/0xa8
[ef115f30] [c004bc40] sys_exit_group+0x14/0x28
[ef115f40] [c0010ef0] ret_from_syscall+0x0/0x4
--- Exception: c01 at 0xfef56c0
    LR = 0xfef5690
Instruction dump:
3949ffd4 91280000 91090004 900b002c 915f0038 900b0030 93ea0038 4bffff8c
814b0030 380b002c 812b002c 912a0000 <91490004> 900b002c 900b0030 4bffff6c
---[ end trace 11d846f2058aa86c ]---
Fixing recursive fault but reboot is needed!
BUG: scheduling while atomic: cryptotest/138/0x00000003
Modules linked in: ocf(P) cryptodev(P) talitos
Call Trace:
[ef115bd0] [c0007a04] show_stack+0x44/0x160 (unreliable)
[ef115c00] [c00392f0] __schedule_bug+0x80/0x84
[ef115c10] [c0541ba0] schedule+0x460/0x638
[ef115c90] [c004bb00] do_exit+0x62c/0x6b0
[ef115ce0] [c000dfa4] die+0xf0/0x224
[ef115d10] [c001523c] bad_page_fault+0x90/0xc8
[ef115d20] [c00113a8] handle_page_fault+0x7c/0x80
--- Exception: 300 at vma_prio_tree_remove+0x118/0x130
    LR = __remove_shared_vm_struct+0x60/0x90
[ef115de0] [c141c0b8] 0xc141c0b8 (unreliable)
[ef115e00] [c00de52c] __remove_shared_vm_struct+0x60/0x90
[ef115e10] [c00de59c] unlink_file_vma+0x40/0x5c


The interrupt error is MDEU AE (address error), but it's really difficult for me to trace the root cause.
I'm not sure why the kernel Oops happens when tried 64 sizes, and it was not always happens, I suspect
it was caused by the same reason with error interrupt.
Moreover, it's ok to run "./cryptotest -va md5 1 8".
Please help me, thanks in advance!




Thanks,
Xufeng Zhang

Re: [Ocf-linux-users] Error thrown by OpenSSL when /dev/crypto exists

[David M. <dav...@mc...>]

Jivin Turner, Greg lays it down ...
> All,
> 
> I am using OCF and OpenSSL to access crypto hardware on the AM37x processor.  OCF 20100325 is used with a 2.6.32 kernel from TI for the AM37x.  OpenSSL 1.0.0d is built with CFLAG?s ?DHAVE_CRYPTODEV and -DUSE_CRYPTODEV_DIGESTS.

Hmm,  I have never used openssl 1.X with or without OCF,  a bit slack I know :-(


> The following errors are being thrown by OpenSSL when generating a self-signed certificate:
> 
> root@am37x-evm:~# openssl req -new -x509 -key privkey.pem -out cacert.pem -days 1095
> 
> You are about to be asked to enter information that will be incorporated
> 
> into your certificate request.
> 
> What you are about to enter is what is called a Distinguished Name or a DN.
> 
> There are quite a few fields but you can leave some blank
> 
> For some fields there will be a default value,
> 
> If you enter '.', the field will be left blank.
> 
> -----
> 
> Country Name (2 letter code) [AU]:US
> 
> State or Province Name (full name) [Some-State]:TX
> 
> Locality Name (eg, city) []:
> 
> Organization Name (eg, company) [Internet Widgits Pty Ltd]:TI
> 
> Organizational Unit Name (eg, section) []:
> 
> Common Name (eg, YOUR name) []:
> 
> Email Address []:
> 
> 1073868400:error:0606B06E:digital envelope routines:EVP_SignFinal:wrong public key type:p_sign.c:125:
> 
> 1073868400:error:0D0C3006:asn1 encoding routines:ASN1_item_sign:EVP lib:a_sign.c:279:
> 
> root@am37x-evm:~# 
> 
> root@am37x-evm:~#
> 
>  
> 
> If I remove /dev/crypto, the error does not occur.  Has anyone else seen this issue?  Is this a known issue that is maybe fixed in the newer OCF version?

Sounds like a definate OCF issue of some sort ;-)

I don't expect thats it's been fixed.  But its hard to say.  I don't know
what driver you are using that is providing OCF PKI ops.

There have been a number of cryptosoft fixes and various little fixes but I
don't recall any PKI specific ones.

If you can,  trying a newer version won't hurt.  Just be warned that I do
not know the status of the OCF work in openssl 1.X,  I oushed a lot of
changes up a long time ago but have never really had the chance to follow up
on what went in and what didn't.

Cheers,
Davidm

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

Re: [Ocf-linux-users] Benchmarking issues

[Turner, G. <gre...@ti...>]

Adam,
Have you also tried using "time -v" in front of your OpenSSL speed test command.

Something like:
# time -v openssl speed -elapsed -evp aes-128-cbc

Try it with and without acceleration.  It will report CPU usage and you can use this interpret how much CPU bandwidth you gain by offloading crypto to the accelerators.


Regards,
Greg Turner


-----Original Message-----
From: "Adam Cécile (Le_Vert)" [mailto:ga...@le...] 
Sent: Thursday, September 01, 2011 7:37 AM
To: ocf...@li...
Subject: Re: [Ocf-linux-users] Benchmarking issues

On 01/09/2011 13:54, David McCullough wrote:
> Jivin "Adam Cécile (Le_Vert)" lays it down ...
>> Hello OCF guys,
>>
>> I'm trying to enable ocf on a Geode LX cpu wich is known to handle
>> aes-128-cbc trhough geode-aes kernel module.
>> I rebuilt linux-3.0 with OCF kernel patch and then rebuilt openssl
>> debian's package with -DHAVE_CRYPTODEV -I$(CURDIR)/debian/includes (this
>> directory contains crypto/cryptodev.h)
>> Then I loaded ocf, cryptosoft and cryptodev kernel modules...
>>
>> Here is the result of my tests using different cipher:
>>
>> # With OpenSSL 1.0.0d cryptodev enabled package
>> # openssl speed -evp<cipher>
>> aes-128-cbc      16761.07k    58822.40k   240275.91k   547942.40k
>> 3126886.40k
>> bf-cbc           13351.73k    67366.40k   191564.80k   715946.67k
>> 1298432.00k
>> des-ede3-cbc     30708.80k    88375.47k   186675.20k
>> 415846.40k         infk
>>
>> #rmmod cryptodev
>> aes-128-cbc       3595.73k     3942.16k     4062.50k     8154.89k
>> 8244.06k
>> bf-cbc            8260.17k    10052.27k    10728.30k    10923.12k
>> 10929.06k
>> des-ede3-cbc      1961.65k     2046.67k     2071.55k     2076.43k
>> 2074.03k
>>
>> Results without cryptodev looks fine (slow 500Mhz CPU) but the ones with
>> cryptodev loaded doesn't make any sense !
>> There's no reason to have such faster blowfish and des results, as the
>> hardware chip only handles aes-128-cbc.
>> Could you please tell me what I'm doing wrong ???
> Add the "-elapsed" option to openssl speed to get real numbers.
> Otherwise it doesn't count kernel time IIRC,
>
> Cheers,
> Davidm
>
Thanks, it looks a lot better now.

# With cryptodev loaded:
# openssl speed -elapsed -evp aes-128-cbc
aes-128-cbc        507.31k     1964.05k     7202.05k    19972.10k    
41997.65k
bf-cbc             538.20k     1801.51k     4496.98k     7171.07k     
8672.60k
des-ede3-cbc       410.43k      883.29k     1236.37k     1385.47k     
1436.33k

# Without cryptodev loaded
aes-128-cbc       3580.90k     3929.60k     4037.89k     8096.77k     
8211.11k
bf-cbc            8249.83k    10068.86k    10702.76k    10904.58k    
10944.51k
des-ede3-cbc      1989.86k     2070.83k     2075.82k     2107.73k     
2106.51k

Is it normal than I have lower bandwitch with cryptodev when the size is 
lower than 256 bytes ?
Btw, cryptodev seems to be slower than regular openssl on non-hardware 
accelerated cipher. Anyway to enable cryptodev ONLY for aes-128-cbc ?

Regards, Adam !

------------------------------------------------------------------------------
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better 
price-free! And you'll get a free "Love Thy Logs" t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev
_______________________________________________
Ocf-linux-users mailing list
Ocf...@li...
https://lists.sourceforge.net/lists/listinfo/ocf-linux-users

[Ocf-linux-users] Error thrown by OpenSSL when /dev/crypto exists

[Turner, G. <gre...@ti...>]

All,
I am using OCF and OpenSSL to access crypto hardware on the AM37x processor.  OCF 20100325 is used with a 2.6.32 kernel from TI for the AM37x.  OpenSSL 1.0.0d is built with CFLAG's -DHAVE_CRYPTODEV and -DUSE_CRYPTODEV_DIGESTS.

The following errors are being thrown by OpenSSL when generating a self-signed certificate:

root@am37x-evm:~# openssl req -new -x509 -key privkey.pem -out cacert.pem -days 1095
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:TX
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:TI
Organizational Unit Name (eg, section) []:
Common Name (eg, YOUR name) []:
Email Address []:
1073868400:error:0606B06E:digital envelope routines:EVP_SignFinal:wrong public key type:p_sign.c:125:
1073868400:error:0D0C3006:asn1 encoding routines:ASN1_item_sign:EVP lib:a_sign.c:279:
root@am37x-evm:~#
root@am37x-evm:~#

If I remove /dev/crypto, the error does not occur.  Has anyone else seen this issue?  Is this a known issue that is maybe fixed in the newer OCF version?

Thanks in advance.



Regards,

Greg Turner

Texas Instruments

(214) 480-1001

Re: [Ocf-linux-users] Benchmarking issues

[David M. <dav...@mc...>]

Jivin "Adam Cécile (Le_Vert)" lays it down ...
> On 01/09/2011 13:54, David McCullough wrote:
> > Jivin "Adam C??cile (Le_Vert)" lays it down ...
> >> Hello OCF guys,
> >>
> >> I'm trying to enable ocf on a Geode LX cpu wich is known to handle
> >> aes-128-cbc trhough geode-aes kernel module.
> >> I rebuilt linux-3.0 with OCF kernel patch and then rebuilt openssl
> >> debian's package with -DHAVE_CRYPTODEV -I$(CURDIR)/debian/includes (this
> >> directory contains crypto/cryptodev.h)
> >> Then I loaded ocf, cryptosoft and cryptodev kernel modules...
> >>
> >> Here is the result of my tests using different cipher:
> >>
> >> # With OpenSSL 1.0.0d cryptodev enabled package
> >> # openssl speed -evp<cipher>
> >> aes-128-cbc      16761.07k    58822.40k   240275.91k   547942.40k
> >> 3126886.40k
> >> bf-cbc           13351.73k    67366.40k   191564.80k   715946.67k
> >> 1298432.00k
> >> des-ede3-cbc     30708.80k    88375.47k   186675.20k
> >> 415846.40k         infk
> >>
> >> #rmmod cryptodev
> >> aes-128-cbc       3595.73k     3942.16k     4062.50k     8154.89k
> >> 8244.06k
> >> bf-cbc            8260.17k    10052.27k    10728.30k    10923.12k
> >> 10929.06k
> >> des-ede3-cbc      1961.65k     2046.67k     2071.55k     2076.43k
> >> 2074.03k
> >>
> >> Results without cryptodev looks fine (slow 500Mhz CPU) but the ones with
> >> cryptodev loaded doesn't make any sense !
> >> There's no reason to have such faster blowfish and des results, as the
> >> hardware chip only handles aes-128-cbc.
> >> Could you please tell me what I'm doing wrong ???
> > Add the "-elapsed" option to openssl speed to get real numbers.
> > Otherwise it doesn't count kernel time IIRC,
> >
> > Cheers,
> > Davidm
> >
> Thanks, it looks a lot better now.
> 
> # With cryptodev loaded:
> # openssl speed -elapsed -evp aes-128-cbc
> aes-128-cbc        507.31k     1964.05k     7202.05k    19972.10k    
> 41997.65k
> bf-cbc             538.20k     1801.51k     4496.98k     7171.07k     
> 8672.60k
> des-ede3-cbc       410.43k      883.29k     1236.37k     1385.47k     
> 1436.33k
> 
> # Without cryptodev loaded
> aes-128-cbc       3580.90k     3929.60k     4037.89k     8096.77k     
> 8211.11k
> bf-cbc            8249.83k    10068.86k    10702.76k    10904.58k    
> 10944.51k
> des-ede3-cbc      1989.86k     2070.83k     2075.82k     2107.73k     
> 2106.51k
> 
> Is it normal than I have lower bandwitch with cryptodev when the size is 
> lower than 256 bytes ?

Yes,  it's the overhead of copying the data into the kernel and back out.
Smaller packets incurrs a higher % overhead per encrypted byte.

> Btw, cryptodev seems to be slower than regular openssl on non-hardware 
> accelerated cipher. Anyway to enable cryptodev ONLY for aes-128-cbc ?

Again,  its the overhead of copying the data to the kernel.  When you do
blowfish or similar in user space its the same code with no copies, for
cryptodev you need to copy the packet into the kernel,  run the cipher, and
copy it back, plus encryption setup time.

The situation where cryptodev pays off is when you have real crypto hardware
and a slow CPU, it frees up CPU time for other tasks and improves speed ;-)

There is currently no way to only have cryptodev to AES,  though all you
need to do is comment out the othe ciphers in cryptosoft and it will only
use cryptodev for AES then, the openssl code will automatically fall back to
internal crypto if cryptodev doesn't have support for an alg. ;-)

Cheers,
Davidm


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

Re: [Ocf-linux-users] Benchmarking issues

[Adam C. (Le_Vert) <ga...@le...>]

On 01/09/2011 13:54, David McCullough wrote:
> Jivin "Adam Cécile (Le_Vert)" lays it down ...
>> Hello OCF guys,
>>
>> I'm trying to enable ocf on a Geode LX cpu wich is known to handle
>> aes-128-cbc trhough geode-aes kernel module.
>> I rebuilt linux-3.0 with OCF kernel patch and then rebuilt openssl
>> debian's package with -DHAVE_CRYPTODEV -I$(CURDIR)/debian/includes (this
>> directory contains crypto/cryptodev.h)
>> Then I loaded ocf, cryptosoft and cryptodev kernel modules...
>>
>> Here is the result of my tests using different cipher:
>>
>> # With OpenSSL 1.0.0d cryptodev enabled package
>> # openssl speed -evp<cipher>
>> aes-128-cbc      16761.07k    58822.40k   240275.91k   547942.40k
>> 3126886.40k
>> bf-cbc           13351.73k    67366.40k   191564.80k   715946.67k
>> 1298432.00k
>> des-ede3-cbc     30708.80k    88375.47k   186675.20k
>> 415846.40k         infk
>>
>> #rmmod cryptodev
>> aes-128-cbc       3595.73k     3942.16k     4062.50k     8154.89k
>> 8244.06k
>> bf-cbc            8260.17k    10052.27k    10728.30k    10923.12k
>> 10929.06k
>> des-ede3-cbc      1961.65k     2046.67k     2071.55k     2076.43k
>> 2074.03k
>>
>> Results without cryptodev looks fine (slow 500Mhz CPU) but the ones with
>> cryptodev loaded doesn't make any sense !
>> There's no reason to have such faster blowfish and des results, as the
>> hardware chip only handles aes-128-cbc.
>> Could you please tell me what I'm doing wrong ???
> Add the "-elapsed" option to openssl speed to get real numbers.
> Otherwise it doesn't count kernel time IIRC,
>
> Cheers,
> Davidm
>
Thanks, it looks a lot better now.

# With cryptodev loaded:
# openssl speed -elapsed -evp aes-128-cbc
aes-128-cbc        507.31k     1964.05k     7202.05k    19972.10k    
41997.65k
bf-cbc             538.20k     1801.51k     4496.98k     7171.07k     
8672.60k
des-ede3-cbc       410.43k      883.29k     1236.37k     1385.47k     
1436.33k

# Without cryptodev loaded
aes-128-cbc       3580.90k     3929.60k     4037.89k     8096.77k     
8211.11k
bf-cbc            8249.83k    10068.86k    10702.76k    10904.58k    
10944.51k
des-ede3-cbc      1989.86k     2070.83k     2075.82k     2107.73k     
2106.51k

Is it normal than I have lower bandwitch with cryptodev when the size is 
lower than 256 bytes ?
Btw, cryptodev seems to be slower than regular openssl on non-hardware 
accelerated cipher. Anyway to enable cryptodev ONLY for aes-128-cbc ?

Regards, Adam !

Re: [Ocf-linux-users] Benchmarking issues

[David M. <dav...@mc...>]

Jivin "Adam Cécile (Le_Vert)" lays it down ...
> Hello OCF guys,
> 
> I'm trying to enable ocf on a Geode LX cpu wich is known to handle 
> aes-128-cbc trhough geode-aes kernel module.
> I rebuilt linux-3.0 with OCF kernel patch and then rebuilt openssl 
> debian's package with -DHAVE_CRYPTODEV -I$(CURDIR)/debian/includes (this 
> directory contains crypto/cryptodev.h)
> Then I loaded ocf, cryptosoft and cryptodev kernel modules...
> 
> Here is the result of my tests using different cipher:
> 
> # With OpenSSL 1.0.0d cryptodev enabled package
> # openssl speed -evp <cipher>
> aes-128-cbc      16761.07k    58822.40k   240275.91k   547942.40k  
> 3126886.40k
> bf-cbc           13351.73k    67366.40k   191564.80k   715946.67k  
> 1298432.00k
> des-ede3-cbc     30708.80k    88375.47k   186675.20k   
> 415846.40k         infk
> 
> #rmmod cryptodev
> aes-128-cbc       3595.73k     3942.16k     4062.50k     8154.89k     
> 8244.06k
> bf-cbc            8260.17k    10052.27k    10728.30k    10923.12k    
> 10929.06k
> des-ede3-cbc      1961.65k     2046.67k     2071.55k     2076.43k     
> 2074.03k
> 
> Results without cryptodev looks fine (slow 500Mhz CPU) but the ones with 
> cryptodev loaded doesn't make any sense !
> There's no reason to have such faster blowfish and des results, as the 
> hardware chip only handles aes-128-cbc.
> Could you please tell me what I'm doing wrong ???

Add the "-elapsed" option to openssl speed to get real numbers.
Otherwise it doesn't count kernel time IIRC,

Cheers,
Davidm

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

[Ocf-linux-users] Benchmarking issues

[Adam C. (Le_Vert) <ga...@le...>]

Hello OCF guys,

I'm trying to enable ocf on a Geode LX cpu wich is known to handle 
aes-128-cbc trhough geode-aes kernel module.
I rebuilt linux-3.0 with OCF kernel patch and then rebuilt openssl 
debian's package with -DHAVE_CRYPTODEV -I$(CURDIR)/debian/includes (this 
directory contains crypto/cryptodev.h)
Then I loaded ocf, cryptosoft and cryptodev kernel modules...

Here is the result of my tests using different cipher:

# With OpenSSL 1.0.0d cryptodev enabled package
# openssl speed -evp <cipher>
aes-128-cbc      16761.07k    58822.40k   240275.91k   547942.40k  
3126886.40k
bf-cbc           13351.73k    67366.40k   191564.80k   715946.67k  
1298432.00k
des-ede3-cbc     30708.80k    88375.47k   186675.20k   
415846.40k         infk

#rmmod cryptodev
aes-128-cbc       3595.73k     3942.16k     4062.50k     8154.89k     
8244.06k
bf-cbc            8260.17k    10052.27k    10728.30k    10923.12k    
10929.06k
des-ede3-cbc      1961.65k     2046.67k     2071.55k     2076.43k     
2074.03k

Results without cryptodev looks fine (slow 500Mhz CPU) but the ones with 
cryptodev loaded doesn't make any sense !
There's no reason to have such faster blowfish and des results, as the 
hardware chip only handles aes-128-cbc.
Could you please tell me what I'm doing wrong ???

Thanks a lot in advance,

Regards, Adam.