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

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

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

Jivin Vrabete, Brad lays it down ...
> Hi there,
>  
> Has anyone tried to compile/run OCF on a 64 bit platform? Any issues?

Works here for me,  the only problem was somewhere in the RNG support,
and that currently disables itself for long != 32 bits IIRC.

I have run it on x86_64 (le) and mips64 (be),

Cheers,
Davidm

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

[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.

Re: [Ocf-linux-users] cryptodev using "native" crypto driver

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

Jivin Kim Phillips lays it down ...
> On Tue, 21 Apr 2009 09:04:46 -0500
> Xianghua Xiao <x....@fr...> wrote:
> 
> > the 2.6.28 kernel/BSP I used does have the newest talitos.c, the same as 
> > 2.6.30-rc2 from herbert's git tree.
> 
> I can't tell which of Herbert's trees you're talking about.
> 
> If /proc/crypto contains cbc-3des-talitos and cbc-aes-talitos entries,
> and cryptosoft is loaded, and you're getting the same performance as
> when no talitos h/w driver is loaded, then it sounds like you've found
> a bug.

Yep,  and it's possible that cryptosoft needs a patch to handle async
crypto drivers.  I think I have one in my inbox or perhaps it was posted
to the list.

Let me know if your talitos support is good and I'll go digging for the
cryptosoft changes you will need,

Cheers,
Davidm

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

Re: [Ocf-linux-users] cryptodev using "native" crypto driver

[Kim P. <kim...@fr...>]

On Tue, 21 Apr 2009 09:04:46 -0500
Xianghua Xiao <x....@fr...> wrote:

> the 2.6.28 kernel/BSP I used does have the newest talitos.c, the same as 
> 2.6.30-rc2 from herbert's git tree.

I can't tell which of Herbert's trees you're talking about.

If /proc/crypto contains cbc-3des-talitos and cbc-aes-talitos entries,
and cryptosoft is loaded, and you're getting the same performance as
when no talitos h/w driver is loaded, then it sounds like you've found
a bug.

Kim

Re: [Ocf-linux-users] cryptodev using "native" crypto driver

[Xianghua X. <x....@fr...>]

the 2.6.28 kernel/BSP I used does have the newest talitos.c, the same as 
2.6.30-rc2 from herbert's git tree.

thanks,
xianghua

Kim Phillips wrote:
> On Mon, 20 Apr 2009 17:10:52 -0500
> Xianghua Xiao <x....@fr...> wrote:
>
>   
>> compared talitos.c from herbert's git snapshot (2.6.30-rc2) with the 
>> talitos.c I'm using, they're identical. talitos.h does have some 
>> difference, but nothing critical.
>>     
>
> are you sure you're using the right tree?
>
> $ git diff --stat v2.6.28 -- drivers/crypto/talitos.c
>  drivers/crypto/talitos.c |  786 +++++++++++++++++++++++++++++++++-------------
>  1 files changed, 575 insertions(+), 211 deletions(-)
>
> Kim
>   

Re: [Ocf-linux-users] cryptodev using "native" crypto driver

[Kim P. <kim...@fr...>]

On Mon, 20 Apr 2009 17:10:52 -0500
Xianghua Xiao <x....@fr...> wrote:

> compared talitos.c from herbert's git snapshot (2.6.30-rc2) with the 
> talitos.c I'm using, they're identical. talitos.h does have some 
> difference, but nothing critical.

are you sure you're using the right tree?

$ git diff --stat v2.6.28 -- drivers/crypto/talitos.c
 drivers/crypto/talitos.c |  786 +++++++++++++++++++++++++++++++++-------------
 1 files changed, 575 insertions(+), 211 deletions(-)

Kim

Re: [Ocf-linux-users] cryptodev using "native" crypto driver

[Xianghua X. <x....@fr...>]

compared talitos.c from herbert's git snapshot (2.6.30-rc2) with the 
talitos.c I'm using, they're identical. talitos.h does have some 
difference, but nothing critical.

i ran "openssl speed -elapsed -cpu -engine cryptodev" which tries all 
crypto algorithms, still I got all zeros cpu times. the talitos.ko also 
gives zero interrupts. again, setkey-based ipsec works well with the 
same talitos driver.
------------------------------------
~/ocf # openssl speed -elapsed -cpu -cpu -engine cryptodev
WARNING: can't open config file: /usr/ssl/openssl.cnf
engine "cryptodev" set.
You have chosen to measure elapsed time instead of user CPU time.
To get the most accurate results, try to run this
program when this computer is idle.
Doing md2 for 3s on 16 size blocks: 99724 md2's in 0.00s
Doing md2 for 3s on 64 size blocks: 51982 md2's in 2147483647.0s
Doing md2 for 3s on 256 size blocks: 17851 md2's in 0.00s
Doing md2 for 3s on 1024 size blocks: 4923 md2's in 0.00s
Doing md2 for 3s on 2048 size blocks: 2504 md2's in 0.00s
Doing md4 for 3s on 16 size blocks: 1137021 md4's in 0.00s
Doing md4 for 3s on 64 size blocks: 965787 md4's in 0.00s
Doing md4 for 3s on 256 size blocks: 706284 md4's in 0.00s
Doing md4 for 3s on 1024 size blocks: 343961 md4's in 0.00s
Doing md4 for 3s on 2048 size blocks: 204119 md4's in 0.00s
Doing md5 for 3s on 16 size blocks: 967079 md5's in 0.00s
Doing md5 for 3s on 64 size blocks: 797822 md5's in 0.00s
Doing md5 for 3s on 256 size blocks: 552616 md5's in 0.00s
Doing md5 for 3s on 1024 size blocks: 249308 md5's in 0.00s
Doing md5 for 3s on 2048 size blocks: 143944 md5's in 0.00s
Doing hmac(md5) for 3s on 16 size blocks: 1136409 hmac(md5)'s in 0.00s
Doing hmac(md5) for 3s on 64 size blocks: 912028 hmac(md5)'s in 0.00s
Doing hmac(md5) for 3s on 256 size blocks: 606583 hmac(md5)'s in 0.00s
Doing hmac(md5) for 3s on 1024 size blocks: 259588 hmac(md5)'s in 0.00s
Doing hmac(md5) for 3s on 2048 size blocks: 147346 hmac(md5)'s in 0.00s
Doing sha1 for 3s on 16 size blocks: 979827 sha1's in 0.00s
Doing sha1 for 3s on 64 size blocks: 784609 sha1's in 2147483647.0s
Doing sha1 for 3s on 256 size blocks: 497955 sha1's in 0.00s
Doing sha1 for 3s on 1024 size blocks: 203198 sha1's in 0.00s
Doing sha1 for 3s on 2048 size blocks: 113558 sha1's in 0.00s
Doing sha256 for 3s on 16 size blocks: 817807 sha256's in 0.00s
Doing sha256 for 3s on 64 size blocks: 494637 sha256's in 0.00s
Doing sha256 for 3s on 256 size blocks: 230091 sha256's in 0.00s
Doing sha256 for 3s on 1024 size blocks: 73428 sha256's in 0.00s
Doing sha256 for 3s on 2048 size blocks: 38488 sha256's in 0.00s
Doing sha512 for 3s on 16 size blocks: 181366 sha512's in 0.00s
Doing sha512 for 3s on 64 size blocks: 180995 sha512's in 0.00s
Doing sha512 for 3s on 256 size blocks: 66900 sha512's in 0.00s
Doing sha512 for 3s on 1024 size blocks: 23449 sha512's in 0.00s
Doing sha512 for 3s on 2048 size blocks: 12567 sha512's in 0.00s
Doing rmd160 for 3s on 16 size blocks: 814302 rmd160's in 0.00s
Doing rmd160 for 3s on 64 size blocks: 602075 rmd160's in 0.00s
Doing rmd160 for 3s on 256 size blocks: 338620 rmd160's in 0.00s
Doing rmd160 for 3s on 1024 size blocks: 123634 rmd160's in 0.00s
Doing rmd160 for 3s on 2048 size blocks: 66941 rmd160's in 0.00s
Doing rc4 for 3s on 16 size blocks: 10996110 rc4's in 0.00s
Doing rc4 for 3s on 64 size blocks: 3256984 rc4's in 0.00s
Doing rc4 for 3s on 256 size blocks: 853415 rc4's in 0.00s
Doing rc4 for 3s on 1024 size blocks: 215958 rc4's in 0.00s
Doing rc4 for 3s on 2048 size blocks: 108198 rc4's in 0.00s
Doing des cbc for 3s on 16 size blocks: 2223476 des cbc's in 0.00s
Doing des cbc for 3s on 64 size blocks: 592607 des cbc's in 0.00s
Doing des cbc for 3s on 256 size blocks: 150612 des cbc's in 0.00s
Doing des cbc for 3s on 1024 size blocks: 37810 des cbc's in 0.00s
Doing des cbc for 3s on 2048 size blocks: 18919 des cbc's in 0.00s
Doing des ede3 for 3s on 16 size blocks: 842233 des ede3's in 0.00s
Doing des ede3 for 3s on 64 size blocks: 216120 des ede3's in 0.00s
Doing des ede3 for 3s on 256 size blocks: 54372 des ede3's in 0.00s
Doing des ede3 for 3s on 1024 size blocks: 13615 des ede3's in 0.00s
Doing des ede3 for 3s on 2048 size blocks: 6809 des ede3's in 0.00s
Doing aes-128 cbc for 3s on 16 size blocks: INFO: task migration/1:6 
blocked for more than
 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
migration/1   D 00000000     0     6      2
Call Trace:
[ef845e70] [deadbeef] 0xdeadbeef (unreliable)
[ef845f30] [c0007928] __switch_to+0x8c/0xdc
[ef845f50] [c03c94cc] schedule+0x214/0x5f0
[ef845fd0] [c00545cc] kthread+0x30/0x84
[ef845ff0] [c000ef24] kernel_thread+0x4c/0x68
INFO: task ksoftirqd/1:7 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
ksoftirqd/1   D 00000000     0     7      2
Call Trace:
[ef849e70] [deadbeef] 0xdeadbeef (unreliable)
[ef849f30] [c0007928] __switch_to+0x8c/0xdc
[ef849f50] [c03c94cc] schedule+0x214/0x5f0
[ef849fd0] [c00545cc] kthread+0x30/0x84
[ef849ff0] [c000ef24] kernel_thread+0x4c/0x68
INFO: task watchdog/1:8 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
watchdog/1    D 00000000     0     8      2
Call Trace:
[ef84be70] [deadbeef] 0xdeadbeef (unreliable)
[ef84bf30] [c0007928] __switch_to+0x8c/0xdc
[ef84bf50] [c03c94cc] schedule+0x214/0x5f0
[ef84bfd0] [c00545cc] kthread+0x30/0x84
[ef84bff0] [c000ef24] kernel_thread+0x4c/0x68
4043240 aes-128 cbc's in 0.00s
Doing aes-128 cbc for 3s on 64 size blocks: 1151532 aes-128 cbc's in 0.00s
Doing aes-128 cbc for 3s on 256 size blocks: 295851 aes-128 cbc's in 0.00s
Doing aes-128 cbc for 3s on 1024 size blocks: 74493 aes-128 cbc's in 0.00s
Doing aes-128 cbc for 3s on 2048 size blocks: 37265 aes-128 cbc's in 0.00s
Doing aes-192 cbc for 3s on 16 size blocks: 3758279 aes-192 cbc's in 0.00s
Doing aes-192 cbc for 3s on 64 size blocks: 1020032 aes-192 cbc's in 0.00s
Doing aes-192 cbc for 3s on 256 size blocks: 261262 aes-192 cbc's in 
2147483647.0s
Doing aes-192 cbc for 3s on 1024 size blocks: 65722 aes-192 cbc's in 0.00s
Doing aes-192 cbc for 3s on 2048 size blocks: 32873 aes-192 cbc's in 
2147483647.0s
Doing aes-256 cbc for 3s on 16 size blocks: 3400667 aes-256 cbc's in 0.00s
Doing aes-256 cbc for 3s on 64 size blocks: 915476 aes-256 cbc's in 0.00s
Doing aes-256 cbc for 3s on 256 size blocks: 233892 aes-256 cbc's in 0.00s
Doing aes-256 cbc for 3s on 1024 size blocks: 58799 aes-256 cbc's in 0.00s
Doing aes-256 cbc for 3s on 2048 size blocks: 29412 aes-256 cbc's in 0.00s
Doing aes-128 ige for 3s on 16 size blocks: 3873740 aes-128 ige's in 0.00s
Doing aes-128 ige for 3s on 64 size blocks: 1137303 aes-128 ige's in 0.00s
Doing aes-128 ige for 3s on 256 size blocks: 298027 aes-128 ige's in 0.00s
Doing aes-128 ige for 3s on 1024 size blocks: 75414 aes-128 ige's in 0.00s
Doing aes-128 ige for 3s on 2048 size blocks: 37760 aes-128 ige's in 0.00s
Doing aes-192 ige for 3s on 16 size blocks: 3494993 aes-192 ige's in 0.00s
Doing aes-192 ige for 3s on 64 size blocks: 1008886 aes-192 ige's in 0.00s
Doing aes-192 ige for 3s on 256 size blocks: 262940 aes-192 ige's in 0.00s
Doing aes-192 ige for 3s on 1024 size blocks: 66442 aes-192 ige's in 0.00s
Doing aes-192 ige for 3s on 2048 size blocks:
~/ocf # cat /proc/interrupts
           CPU0
 14:          0   i8259     Level     pata_ali
 17:          6   OpenPIC   Level     phy_interrupt, phy_interrupt
 18:        380   FSL-MSI   Edge      ahci
 28:          0   OpenPIC   Level     ehci_hcd:usb1
 29:         10   OpenPIC   Level     eth0_tx
 30:      11143   OpenPIC   Level     eth0_rx
 34:          0   OpenPIC   Level     eth0_er
 35:          0   OpenPIC   Level     eth1_tx
 36:          0   OpenPIC   Level     eth1_rx
 40:          0   OpenPIC   Level     eth1_er
 42:       1727   OpenPIC   Level     serial
 43:          0   OpenPIC   Level     i2c-mpc, i2c-mpc
 45:          0   OpenPIC   Level     talitos
 59:          2   OpenPIC   Level     fsl_espi
251:          0   OpenPIC   Edge      ipi call function
252:          0   OpenPIC   Edge      ipi reschedule
253:          0   OpenPIC   Edge      ipi call function single
BAD:          0
~/ocf #

thanks,
xianghua

Kim Phillips wrote:
> On Mon, 20 Apr 2009 14:29:21 -0500
> Xianghua Xiao <x....@fr...> wrote:
>
>   
>> Here is what I tried, patched ocf-linux to 2.6.28, insmod all modules, 
>> run patched openssl 0.9.8i, openssl "completes" all steps in 0 seconds, 
>> something must be wrong.  the in-kernel driver is not even invoked by 
>> looking at interrupts, any idea? Note: i tried ocf/openswan/KLIPS on an 
>>     
>
> try what's sitting in Herbert's cryptodev tree on git.kernel.org
> instead - that driver has support for cbc-mode aes and 3des (which is
> what you are testing here).
>
> also, please don't top-post/full quote.
>
> Thanks,
>
> Kim
>   

Re: [Ocf-linux-users] cryptodev using "native" crypto driver

[Kim P. <kim...@fr...>]

On Mon, 20 Apr 2009 14:29:21 -0500
Xianghua Xiao <x....@fr...> wrote:

> Here is what I tried, patched ocf-linux to 2.6.28, insmod all modules, 
> run patched openssl 0.9.8i, openssl "completes" all steps in 0 seconds, 
> something must be wrong.  the in-kernel driver is not even invoked by 
> looking at interrupts, any idea? Note: i tried ocf/openswan/KLIPS on an 

try what's sitting in Herbert's cryptodev tree on git.kernel.org
instead - that driver has support for cbc-mode aes and 3des (which is
what you are testing here).

also, please don't top-post/full quote.

Thanks,

Kim

Re: [Ocf-linux-users] cryptodev using "native" crypto driver

[Xianghua X. <x....@fr...>]

Here is what I tried, patched ocf-linux to 2.6.28, insmod all modules, 
run patched openssl 0.9.8i, openssl "completes" all steps in 0 seconds, 
something must be wrong.  the in-kernel driver is not even invoked by 
looking at interrupts, any idea? Note: i tried ocf/openswan/KLIPS on an 
older kernel and openssl worked there, the in-kernel new driver worked 
when using setkep to set up ipsec, looks like something is wrong with 
the cryptodev stuff:
------------------------------------------
~/ocf # rmmod cryptodev
~/ocf # rmmod cryptosoft
~/ocf # rmmod ocf
~/ocf # lsmod
Module                  Size  Used by
~/ocf # uname -a
Linux mpc8572ds 2.6.28.1-00298-g3cf38ee-dirty #1 SMP Mon Apr 20 10:45:24 
CDT 2009 ppc GNU/
Linux
~/ocf # insmod ./ocf.ko
~/ocf # insmod ./cryptodev.ko
~/ocf # insmod ./cryptosoft.ko
~/ocf # insmod ./talitos.ko
talitos ffe30000.crypto: hwrng
alg: No test for authenc(hmac(sha1),cbc(aes)) 
(authenc-hmac-sha1-cbc-aes-talitos)
talitos ffe30000.crypto: authenc-hmac-sha1-cbc-aes-talitos
alg: No test for authenc(hmac(sha1),cbc(des3_ede)) 
(authenc-hmac-sha1-cbc-3des-talitos)
talitos ffe30000.crypto: authenc-hmac-sha1-cbc-3des-talitos
alg: No test for authenc(hmac(sha256),cbc(aes)) 
(authenc-hmac-sha256-cbc-aes-talitos)
talitos ffe30000.crypto: authenc-hmac-sha256-cbc-aes-talitos
alg: No test for authenc(hmac(sha256),cbc(des3_ede)) 
(authenc-hmac-sha256-cbc-3des-talitos
)
talitos ffe30000.crypto: authenc-hmac-sha256-cbc-3des-talitos
alg: No test for authenc(hmac(md5),cbc(aes)) 
(authenc-hmac-md5-cbc-aes-talitos)
talitos ffe30000.crypto: authenc-hmac-md5-cbc-aes-talitos
alg: No test for authenc(hmac(md5),cbc(des3_ede)) 
(authenc-hmac-md5-cbc-3des-talitos)
talitos ffe30000.crypto: authenc-hmac-md5-cbc-3des-talitos
~/ocf # lsmod
Module                  Size  Used by
talitos                18624  0
cryptosoft             11440  0
cryptodev              14500  0
ocf                    27484  2 cryptosoft,cryptodev
~/ocf # openssl speed -elapsed -evp des-ede3-cbc -engine cryptodev -cpu
WARNING: can't open config file: /usr/ssl/openssl.cnf
engine "cryptodev" set.
You have chosen to measure elapsed time instead of user CPU time.
To get the most accurate results, try to run this
program when this computer is idle.
Doing des-ede3-cbc for 3s on 16 size blocks: 216688 des-ede3-cbc's in 0.00s
Doing des-ede3-cbc for 3s on 64 size blocks: 128415 des-ede3-cbc's in 0.00s
Doing des-ede3-cbc for 3s on 256 size blocks: 48908 des-ede3-cbc's in 0.00s
Doing des-ede3-cbc for 3s on 1024 size blocks: 14127 des-ede3-cbc's in 0.00s
Doing des-ede3-cbc for 3s on 2048 size blocks: 7230 des-ede3-cbc's in 
2147483647.0s
OpenSSL 0.9.8i 15 Sep 2008
built on: Mon Apr 20 12:55:19 CDT 2009
options:bn(64,32) md2(int) rc4(ptr,char) des(idx,risc1,16,long) 
aes(partial) idea(int) blo
wfish(idx)
compiler: gcc -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT 
-DDSO_DLFCN -DHAVE_DLFCN_
H -DHAVE_CRYPTODEV -DB_ENDIAN -DB_ENDIAN -DTERMIO -O3 -Wall
available timing options: TIMES TIMEB HZ=7.41098e-322 [sysconf value]
timing function used: ftime
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes /cpu     64 bytes /cpu    256 bytes /cpu   
1024 bytes /cpu   204
8 bytes /cpu
des-ede3-cbc  
9808352818197981992795330994664242746378032095412947614020858417323457159992
220728377548646966672572860197718924960528369593685784879304276592844431701294994185470557
5506159429746688.00k/%100        0.00k/%100       -0.00k/%100        
0.00k/%100        0.0
0k/%100
~/ocf # openssl speed -elapsed -evp des-ede3-cbc -cpu
WARNING: can't open config file: /usr/ssl/openssl.cnf
You have chosen to measure elapsed time instead of user CPU time.
To get the most accurate results, try to run this
program when this computer is idle.
Doing des-ede3-cbc for 3s on 16 size blocks: 217871 des-ede3-cbc's in 0.00s
Doing des-ede3-cbc for 3s on 64 size blocks: 128680 des-ede3-cbc's in 0.00s
Doing des-ede3-cbc for 3s on 256 size blocks: 48925 des-ede3-cbc's in 0.00s
Doing des-ede3-cbc for 3s on 1024 size blocks: 14103 des-ede3-cbc's in 
2147483647.0s
Doing des-ede3-cbc for 3s on 2048 size blocks: 7234 des-ede3-cbc's in 0.00s
OpenSSL 0.9.8i 15 Sep 2008
built on: Mon Apr 20 12:55:19 CDT 2009
options:bn(64,32) md2(int) rc4(ptr,char) des(idx,risc1,16,long) 
aes(partial) idea(int) blo
wfish(idx)
compiler: gcc -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT 
-DDSO_DLFCN -DHAVE_DLFCN_
H -DHAVE_CRYPTODEV -DB_ENDIAN -DB_ENDIAN -DTERMIO -O3 -Wall
available timing options: TIMES TIMEB HZ=7.41098e-322 [sysconf value]
timing function used: ftime
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes /cpu     64 bytes /cpu    256 bytes /cpu   
1024 bytes /cpu   204
8 bytes /cpu
des-ede3-cbc         0.00k/%100       -0.00k/%100 
-228998953029974311841503602121312208883
817686549574999287274100565424139180729943013547327548632681026770471405511989488440428768
058454816536123474759035841336940483362802472291300266042584629938696157429255554607213800
12589056.00k/%100 
3044265661076964743504699236572542454648112292278445226047045632.00k/%10
0        0.00k/%100
~/ocf # cat /proc/interrupts
           CPU0
 14:          0   i8259     Level     pata_ali
 17:          6   OpenPIC   Level     phy_interrupt, phy_interrupt
 18:        652   FSL-MSI   Edge      ahci
 28:          0   OpenPIC   Level     ehci_hcd:usb1
 29:         16   OpenPIC   Level     eth0_tx
 30:       4816   OpenPIC   Level     eth0_rx
 34:          0   OpenPIC   Level     eth0_er
 35:          0   OpenPIC   Level     eth1_tx
 36:          0   OpenPIC   Level     eth1_rx
 40:          0   OpenPIC   Level     eth1_er
 42:       6874   OpenPIC   Level     serial
 43:          0   OpenPIC   Level     i2c-mpc, i2c-mpc
 45:          0   OpenPIC   Level     talitos
 59:          2   OpenPIC   Level     fsl_espi
251:          0   OpenPIC   Edge      ipi call function
252:          0   OpenPIC   Edge      ipi reschedule
253:          0   OpenPIC   Edge      ipi call function single
BAD:          0
~/ocf #

thanks,
xianghua


xianghua xiao wrote:
> thanks a lot! will give it a try on 2.6.28.
> xianghua
>
> David McCullough wrote:
>   
>> Jivin xianghua xiao lays it down ...
>>   
>>     
>>> David,
>>>
>>> what do you mean by "in-kernel" driver here?
>>>     
>>>       
>> The talitos driver that is part of the recent mainline kernels (ie., it
>> is not provided by OCF).
>>
>> Cheers,
>> Davidm
>>
>>   
>>     
>>> David McCullough wrote:
>>>     
>>>       
>>>> Jivin Xianghua Xiao lays it down ...
>>>>   
>>>>       
>>>>         
>>>>> Hi,
>>>>> I used ocf/cryptodev on talitos driver and it worked well along with 
>>>>> openssl. now with the new talitos driver under drivers/crypto I would 
>>>>> like to use the same application-friendly /dev/crypto interface for 
>>>>> underlying hardware SEC engine. The cryptodev.c from ocf-linux is 
>>>>> dependent on ocf framework. what's needed to get cryptodev working with 
>>>>> new security drivers (e.g. drivers/crypto/talitos.c) where no ocf is 
>>>>> present?
>>>>>     
>>>>>         
>>>>>           
>>>> Use OCF just like before,  but instead of using the ocf talitos driver,
>>>> just use cryptosoft.  cryptosoft whould use the "in-kernel" drivers to
>>>> do it's crypto.
>>>>
>>>> It's not ideal,  but if you are using it just for SSL,  there will be
>>>> little to no penality,
>>>>
>>>> Cheers,
>>>> Davidm
>>>>
>>>>   
>>>>       
>>>>         
>>> ------------------------------------------------------------------------------
>>> Stay on top of everything new and different, both inside and 
>>> around Java (TM) technology - register by April 22, and save
>>> $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
>>> 300 plus technical and hands-on sessions. Register today. 
>>> Use priority code J9JMT32. http://p.sf.net/sfu/p
>>> _______________________________________________
>>> Ocf-linux-users mailing list
>>> Ocf...@li...
>>> https://lists.sourceforge.net/lists/listinfo/ocf-linux-users
>>>
>>>     
>>>       
>>   
>>     
>
>
> ------------------------------------------------------------------------------
> Stay on top of everything new and different, both inside and 
> around Java (TM) technology - register by April 22, and save
> $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
> 300 plus technical and hands-on sessions. Register today. 
> Use priority code J9JMT32. http://p.sf.net/sfu/p
> _______________________________________________
> Ocf-linux-users mailing list
> Ocf...@li...
> https://lists.sourceforge.net/lists/listinfo/ocf-linux-users
>   

Re: [Ocf-linux-users] cryptodev using "native" crypto driver

[xianghua x. <x....@fr...>]

thanks a lot! will give it a try on 2.6.28.
xianghua

David McCullough wrote:
> Jivin xianghua xiao lays it down ...
>   
>> David,
>>
>> what do you mean by "in-kernel" driver here?
>>     
>
> The talitos driver that is part of the recent mainline kernels (ie., it
> is not provided by OCF).
>
> Cheers,
> Davidm
>
>   
>> David McCullough wrote:
>>     
>>> Jivin Xianghua Xiao lays it down ...
>>>   
>>>       
>>>> Hi,
>>>> I used ocf/cryptodev on talitos driver and it worked well along with 
>>>> openssl. now with the new talitos driver under drivers/crypto I would 
>>>> like to use the same application-friendly /dev/crypto interface for 
>>>> underlying hardware SEC engine. The cryptodev.c from ocf-linux is 
>>>> dependent on ocf framework. what's needed to get cryptodev working with 
>>>> new security drivers (e.g. drivers/crypto/talitos.c) where no ocf is 
>>>> present?
>>>>     
>>>>         
>>> Use OCF just like before,  but instead of using the ocf talitos driver,
>>> just use cryptosoft.  cryptosoft whould use the "in-kernel" drivers to
>>> do it's crypto.
>>>
>>> It's not ideal,  but if you are using it just for SSL,  there will be
>>> little to no penality,
>>>
>>> Cheers,
>>> Davidm
>>>
>>>   
>>>       
>> ------------------------------------------------------------------------------
>> Stay on top of everything new and different, both inside and 
>> around Java (TM) technology - register by April 22, and save
>> $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
>> 300 plus technical and hands-on sessions. Register today. 
>> Use priority code J9JMT32. http://p.sf.net/sfu/p
>> _______________________________________________
>> Ocf-linux-users mailing list
>> Ocf...@li...
>> https://lists.sourceforge.net/lists/listinfo/ocf-linux-users
>>
>>     
>
>   

Re: [Ocf-linux-users] cryptodev using "native" crypto driver

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

Jivin xianghua xiao lays it down ...
> David,
> 
> what do you mean by "in-kernel" driver here?

The talitos driver that is part of the recent mainline kernels (ie., it
is not provided by OCF).

Cheers,
Davidm

> David McCullough wrote:
> > Jivin Xianghua Xiao lays it down ...
> >   
> >> Hi,
> >> I used ocf/cryptodev on talitos driver and it worked well along with 
> >> openssl. now with the new talitos driver under drivers/crypto I would 
> >> like to use the same application-friendly /dev/crypto interface for 
> >> underlying hardware SEC engine. The cryptodev.c from ocf-linux is 
> >> dependent on ocf framework. what's needed to get cryptodev working with 
> >> new security drivers (e.g. drivers/crypto/talitos.c) where no ocf is 
> >> present?
> >>     
> >
> > Use OCF just like before,  but instead of using the ocf talitos driver,
> > just use cryptosoft.  cryptosoft whould use the "in-kernel" drivers to
> > do it's crypto.
> >
> > It's not ideal,  but if you are using it just for SSL,  there will be
> > little to no penality,
> >
> > Cheers,
> > Davidm
> >
> >   
> 
> 
> ------------------------------------------------------------------------------
> Stay on top of everything new and different, both inside and 
> around Java (TM) technology - register by April 22, and save
> $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
> 300 plus technical and hands-on sessions. Register today. 
> Use priority code J9JMT32. http://p.sf.net/sfu/p
> _______________________________________________
> Ocf-linux-users mailing list
> Ocf...@li...
> https://lists.sourceforge.net/lists/listinfo/ocf-linux-users
> 

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

Re: [Ocf-linux-users] cryptodev using "native" crypto driver

[xianghua x. <x....@fr...>]

David,

what do you mean by "in-kernel" driver here?
Thanks!

xianghua

David McCullough wrote:
> Jivin Xianghua Xiao lays it down ...
>   
>> Hi,
>> I used ocf/cryptodev on talitos driver and it worked well along with 
>> openssl. now with the new talitos driver under drivers/crypto I would 
>> like to use the same application-friendly /dev/crypto interface for 
>> underlying hardware SEC engine. The cryptodev.c from ocf-linux is 
>> dependent on ocf framework. what's needed to get cryptodev working with 
>> new security drivers (e.g. drivers/crypto/talitos.c) where no ocf is 
>> present?
>>     
>
> Use OCF just like before,  but instead of using the ocf talitos driver,
> just use cryptosoft.  cryptosoft whould use the "in-kernel" drivers to
> do it's crypto.
>
> It's not ideal,  but if you are using it just for SSL,  there will be
> little to no penality,
>
> Cheers,
> Davidm
>
>   

Re: [Ocf-linux-users] cryptodev using "native" crypto driver

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

Jivin Xianghua Xiao lays it down ...
> Hi,
> I used ocf/cryptodev on talitos driver and it worked well along with 
> openssl. now with the new talitos driver under drivers/crypto I would 
> like to use the same application-friendly /dev/crypto interface for 
> underlying hardware SEC engine. The cryptodev.c from ocf-linux is 
> dependent on ocf framework. what's needed to get cryptodev working with 
> new security drivers (e.g. drivers/crypto/talitos.c) where no ocf is 
> present?

Use OCF just like before,  but instead of using the ocf talitos driver,
just use cryptosoft.  cryptosoft whould use the "in-kernel" drivers to
do it's crypto.

It's not ideal,  but if you are using it just for SSL,  there will be
little to no penality,

Cheers,
Davidm

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

[Ocf-linux-users] cryptodev using "native" crypto driver

[Xianghua X. <x....@fr...>]

Hi,
I used ocf/cryptodev on talitos driver and it worked well along with 
openssl. now with the new talitos driver under drivers/crypto I would 
like to use the same application-friendly /dev/crypto interface for 
underlying hardware SEC engine. The cryptodev.c from ocf-linux is 
dependent on ocf framework. what's needed to get cryptodev working with 
new security drivers (e.g. drivers/crypto/talitos.c) where no ocf is 
present?

thanks for any tips,
xianghua

Re: [Ocf-linux-users] OCF compatible driver for HiFN Xcellerator Card 8155HXL-G

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

Jivin hiren joshi lays it down ...
> On Fri, Mar 20, 2009 at 1:02 PM, hiren joshi <jos...@gm...> wrote:
> >
> > Hello David,
> >
> > > > Thanks for pointing to both these things.
> > > > However currently I am stuck as the HiFN driver is written for
> > > > linux-2.4.x and I use linux-2.6.x. :-(
> > >
> > > So the SDK for the Hifn HIPP devices is 2.4 only, thats seems a bit
> > > dodgy.
> > >
> > > I checked my hifn extranet login and couldn't find anything better than
> > > their old 795x source.
> > >
> > > You could try contacting Hank Cohen at hifn, he has helped me in the
> > > past.  Maybe they have something better.
> > >
> > >        Hank Cohen <hc...@hi...>
> > >
> > > Let him know you were talking to me about OCF/HIFN/8155 and were
> > > wondering if they had anything for linux-2.6 in that space.
> > >
> > > Of course the SDK is more than likely 95% OS independant for use with
> > > vxworks/windows/whatever,  so you may be able to use it on almost any OS
> > > without too much work :-(
> >
> > We have already communicated the problem to HiFN.
> > Thank you very much for providing the reference.
> > We will get help from Mr Hank Cohen as needed.
> > I will get back to this as soon as I get something to share.
> 
> Meanwhile I request OCF-users to help me in choosing an acceleration card that -
> 
> 1. supports linux-2.6 (has driver for linux-2.6)
> 2. Has well documented APIs, SDKs that helps me to use it with Openswan/KLIPS
> 
> If possible, please share realtime performance experience and other
> useful things (pros/cons).
> I need to be prepared with an alternate ;-)

Have a look at the cavium NITROX card (PCIe), it has everything you are
asking for and tops out at about 2.5Gbps for some kinds of use.

I am working on one at the moment,  hopefully I will have a better feel
for it once some of my other projects complete and I spend some more
time on it.

It has patches for the linux NETKEY stack IIRC and I think I saw some
patches for ipsec user tools (non-openswan).

Cheers,
Davidm

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

Re: [Ocf-linux-users] OCF compatible driver for HiFN Xcellerator Card 8155HXL-G

[hiren j. <jos...@gm...>]

On Fri, Mar 20, 2009 at 1:02 PM, hiren joshi <jos...@gm...> wrote:
>
> Hello David,
>
> > > Thanks for pointing to both these things.
> > > However currently I am stuck as the HiFN driver is written for
> > > linux-2.4.x and I use linux-2.6.x. :-(
> >
> > So the SDK for the Hifn HIPP devices is 2.4 only, thats seems a bit
> > dodgy.
> >
> > I checked my hifn extranet login and couldn't find anything better than
> > their old 795x source.
> >
> > You could try contacting Hank Cohen at hifn, he has helped me in the
> > past.  Maybe they have something better.
> >
> >        Hank Cohen <hc...@hi...>
> >
> > Let him know you were talking to me about OCF/HIFN/8155 and were
> > wondering if they had anything for linux-2.6 in that space.
> >
> > Of course the SDK is more than likely 95% OS independant for use with
> > vxworks/windows/whatever,  so you may be able to use it on almost any OS
> > without too much work :-(
>
> We have already communicated the problem to HiFN.
> Thank you very much for providing the reference.
> We will get help from Mr Hank Cohen as needed.
> I will get back to this as soon as I get something to share.

Meanwhile I request OCF-users to help me in choosing an acceleration card that -

1. supports linux-2.6 (has driver for linux-2.6)
2. Has well documented APIs, SDKs that helps me to use it with Openswan/KLIPS

If possible, please share realtime performance experience and other
useful things (pros/cons).
I need to be prepared with an alternate ;-)

Thanks for your time.

Regards,
hiren

Re: [Ocf-linux-users] OCF compatible driver for HiFN Xcellerator Card 8155HXL-G

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

Jivin hiren joshi lays it down ...
> Thank you for the much awaited answer!
> 
> >> So I meant to use these features to completely offload
> >> the packet protocol processing (not just crypto operations)
> >> by integrating the HiFN APIs with Openswan(KLIPS).
> >
> > That will be a bit of work and not much that OCF has done to date will
> > help you here.  The state machine in KLIPS which came with the OCF
> > patches should be a good start to doing more IPSec offloading, at least
> > it weas created with that in mind at some point in the future :-)
> 
> >> Considering the complete protocol processing offloading,
> >> I will have to find new hook points in KLIPS.
> >
> > Yes,  the TX and RX state machine should give you most of those hooks.
> > You should be able to do some like:
> >
> >        init state
> >        (hand off)
> >        skip to final state
> 
> Thanks for pointing to both these things.
> However currently I am stuck as the HiFN driver is written for
> linux-2.4.x and I use linux-2.6.x. :-(

So the SDK for the Hifn HIPP devices is 2.4 only, thats seems a bit
dodgy.

I checked my hifn extranet login and couldn't find anything better than
their old 795x source.

You could try contacting Hank Cohen at hifn, he has helped me in the
past.  Maybe they have something better.

	Hank Cohen <hc...@hi...>

Let him know you were talking to me about OCF/HIFN/8155 and were
wondering if they had anything for linux-2.6 in that space.

Of course the SDK is more than likely 95% OS independant for use with
vxworks/windows/whatever,  so you may be able to use it on almost any OS
without too much work :-(

Cheers,
Davidm

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

Re: [Ocf-linux-users] OCF compatible driver for HiFN Xcellerator Card 8155HXL-G

[hiren j. <jos...@gm...>]

Thank you for the much awaited answer!

>> So I meant to use these features to completely offload
>> the packet protocol processing (not just crypto operations)
>> by integrating the HiFN APIs with Openswan(KLIPS).
>
> That will be a bit of work and not much that OCF has done to date will
> help you here.  The state machine in KLIPS which came with the OCF
> patches should be a good start to doing more IPSec offloading, at least
> it weas created with that in mind at some point in the future :-)

>> Considering the complete protocol processing offloading,
>> I will have to find new hook points in KLIPS.
>
> Yes,  the TX and RX state machine should give you most of those hooks.
> You should be able to do some like:
>
>        init state
>        (hand off)
>        skip to final state

Thanks for pointing to both these things.
However currently I am stuck as the HiFN driver is written for
linux-2.4.x and I use linux-2.6.x. :-(

Thanks again,
hiren

Re: [Ocf-linux-users] OCF compatible driver for HiFN Xcellerator Card 8155HXL-G

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

Jivin hiren joshi lays it down ...
> >> 1. With OCF: Incorporate OCF glue in the existing driver I got with SDK.
> >> It will allow other sub-systems and applications to use the card.
> >> (As I have only one card, session migration is not relevant here.)
> >
> > Whatever you feel works the best.  Starting with an existing OCF driver
> > and swapping the API calls to the hifn API would seem easiest to me,
> > but that is your call.
> 
> Thank you for suggesting this.
> 
> >> 2. Without OCF: Native integration with Openswan (KLIPS) using the SDK APIs.
> >> This will help me to get full advantage of the card (protocol
> >> processing offloading).
> >
> > The overhead that OCF adds to the crypto process is very small.  I did
> > this test with the IXP driver (look at ocf-bench.c to see the IXP native
> > and OCF parts of the test).
> 
> I should have been more wordy here.
> What I mean by protocol processing offloading is -
> 
> besides crypto, compression and randomization,
> the 8155 (HIPP II family, DS-250/255 series) card supports
> following packet processing protocols:
> 
> - IPSec - AH, ESP, Transport and Tunnel mode,
> - UDP encapsulation for NAT-T,

Currently we have nothing that can take advantage of these.

> - IKE,

You may be able to take advantage of these,  most certainly some of the
bignum operations if they are offered (ie., CRT).

> - SSL/TSL/DTLS,

Probably not much you can use here.

> - Raw cryptographic transforms

Obviously these should be useful :-).

> So I meant to use these features to completely offload
> the packet protocol processing (not just crypto operations)
> by integrating the HiFN APIs with Openswan(KLIPS).

That will be a bit of work and not much that OCF has done to date will
help you here.  The state machine in KLIPS which came with the OCF
patches should be a good start to doing more IPSec offloading, at least
it weas created with that in mind at some point in the future :-)

> > There was almost no reduction in crypto speed (IIRC < 1%).  This
> > basically means that #1 above is the best choice,  and it saves you have
> > to do anything in the openswan code and also lets you accelerate openssl
> > and potentially other things.
> 
> Considering the complete protocol processing offloading,
> I will have to find new hook points in KLIPS.

Yes,  the TX and RX state machine should give you most of those hooks.
You should be able to do some like:

	init state
	(hand off)
	skip to final state

> Are there any efforts going on (OCF-2?) that let us use
> these new features of such cards?

No, OCF-2 didn't turn into anything I could see.

Cheers,
Davidm

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

Re: [Ocf-linux-users] OCF inbuilt and 2.6.27

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

Jivin Daniel Mueller lays it down ...
> On Tue, 17 Mar 2009 10:38:47 +1000 David McCullough wrote:
> 
> > [.. snip ..]
> > Use the talitos driver as an example.  From what I have seen it should
> > be fairly easy to follow.
> 
> Thanks for all this information. I'll have a look at it. 
> 
> BTW: the ubsec_ssb OCF driver is now part of OpenWRT [1]. I got


Did you want to send in a copy to include in ocf-linux  ?

> positive feedback from a few people. The only application(s) that can
> be accelerated at the moment is libopenssl with OpenSSH. 
> 
> I am still having problems with OpenSWAN. Unfortunately packets that
> need to be forwarded from one network (e.g. LAN1) to another network
> (e.g. Wifi) are not 32bit memory aligned. So in-place
> encryption/decryption does not work here (HW requires 32bit aligned
> memory for its output data buffer). I couldn't figure out why this
> happens - maybe it's the network(-switch) driver, that uses VLAN tags.
> If I were allowed to use a different (aligned) memory address for the
> output data I could extend the driver to work like this.

You could add a local buffer to each session in your driver,  and,  if
the request was unaligned, output to it and copy back when done.

On these slow CPU's a memcpy of a 1000 bytes is still much faster than
the crypto op.  That would at least get you working transparently and
allow you to use it for openswan ;-)

Cheers,
Davidm

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

Re: [Ocf-linux-users] OCF inbuilt and 2.6.27

[Daniel M. <da...@da...>]

On Tue, 17 Mar 2009 10:38:47 +1000 David McCullough wrote:

> [.. snip ..]
> Use the talitos driver as an example.  From what I have seen it should
> be fairly easy to follow.

Thanks for all this information. I'll have a look at it. 

BTW: the ubsec_ssb OCF driver is now part of OpenWRT [1]. I got
positive feedback from a few people. The only application(s) that can
be accelerated at the moment is libopenssl with OpenSSH. 

I am still having problems with OpenSWAN. Unfortunately packets that
need to be forwarded from one network (e.g. LAN1) to another network
(e.g. Wifi) are not 32bit memory aligned. So in-place
encryption/decryption does not work here (HW requires 32bit aligned
memory for its output data buffer). I couldn't figure out why this
happens - maybe it's the network(-switch) driver, that uses VLAN tags.
If I were allowed to use a different (aligned) memory address for the
output data I could extend the driver to work like this.

Driver details:
Hardware: bcm5365p (IPSec core)
Platform: MIPS (little endian)
Device: Asus WL500gP
Bus: SSB (Sonic Silicon Backplane)
Implemented algos: (3)DES, AES (128,192,256), MD5-HMAC, SHA-1-HMAC
Original BSD driver source: OpenBSD (ubsec x86 PCI (3)DES accelerator)

[1] https://dev.openwrt.org/browser/trunk/package/ubsec_ssb/src

bye,
Daniel
-- 
Daniel Mueller          http://www.danm.de
Berlin, Germany         OpenPGP: F9F982C1

Re: [Ocf-linux-users] OCF inbuilt and 2.6.27

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

Jivin Daniel Mueller lays it down ...
> On Mon, 16 Mar 2009 16:41:12 +1000 David McCullough wrote:
> 
> > OCF is not moving into the kernel,  not ever.  The licensing was one
> > of the major stumbing blocks.
> 
> I have just checked kernel 2.6.28.7 and I found (native) drivers for
> 
> - VIA's Padlock
> - AMD's Geode AES engine
> - Intel's IXP4xx NPE-C
> - Freescale's Integrated Security Engine (talitos)
> - HIFN 795x crypto accelerator
> 
> That's definitely more than two years ago.

Absolutely,  and the crypto guys a fixing stuff all the time.  A
serialised async ipsec patch was posted today.  All of this native
linux crypto is slowly coming together.

> I am now asking myself why not write native Linux drivers instead of
> OCF modules and use the cryptodev (/dev/crypto) interface only?

There is nothing wrong with that approach at all,  and if linux is your
focus,  and you would like your work to be mainlined, thats the only
approach to chose.

> I have
> read the OCF documentation and I know that David would like other OS
> projects (e.g. OpenBSD or FreeBSD) to benefit from new/improved
> drivers.

There were lots of reasons OCF never had a chance to make it into the
kernel.  Firstly, the licensing,  and since I reused so much of the OCF
code there was no way I could change the license without permission from
all the listed authors.  Understandably a number of them refused to
allow it to be released under a Dual BSD/GPL license.  So it had to
stick with BSD.

> I can hardly imagine that new drivers can be adopted without
> porting efforts.

Yes,  but the porting is purely at the HW level,  all the "API" bits
stay the same.

> I myself would rather write a native driver and distribute it with
> dual license (GPL/BSD). The only reason I didn't managed it yet was the
> lack of documentation of Linux's async crypto API ;-)

Use the talitos driver as an example.  From what I have seen it should
be fairly easy to follow.

> A native driver could be used for
> - kernel IPSec
> - luks/dm-crypt
> - ..
> 
> The cryptodev/cryptosoft interface is still needed for user space
> applications such as OpenSSL. If those two parts where GPL licensed 
> the acceptance for kernel inclusion could raise. Or do I forget
> something important here?

There have already be patches posted for a kernel crypto API user
interface,  however,  there is a tendancy to avoid it,  even if it isn't
OCF.  Just the linux-crypto mailing list or look through the archives
for all the OCF and other user mode interface discussions.

Current thinking is that they would rather move the bulk crypto into the
kernel as a full SSL socket type than use an user-kernel API to do the
crypto.  This is good in that it gives you really high performance SSL
connections,  downside is that you have to wait for it to arrive ;-)

In the interim,  using cryptosoft and cryptodev with native kernel
crypto drivers is an easy way to keep working while they sort it out,

Cheers,
Davidm

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

Re: [Ocf-linux-users] OCF inbuilt and 2.6.27

[Daniel M. <da...@da...>]

On Mon, 16 Mar 2009 16:41:12 +1000 David McCullough wrote:

> OCF is not moving into the kernel,  not ever.  The licensing was one
> of the major stumbing blocks.

I have just checked kernel 2.6.28.7 and I found (native) drivers for

- VIA's Padlock
- AMD's Geode AES engine
- Intel's IXP4xx NPE-C
- Freescale's Integrated Security Engine (talitos)
- HIFN 795x crypto accelerator

That's definitely more than two years ago.

I am now asking myself why not write native Linux drivers instead of
OCF modules and use the cryptodev (/dev/crypto) interface only? I have
read the OCF documentation and I know that David would like other OS
projects (e.g. OpenBSD or FreeBSD) to benefit from new/improved
drivers. I can hardly imagine that new drivers can be adopted without
porting efforts.

I myself would rather write a native driver and distribute it with
dual license (GPL/BSD). The only reason I didn't managed it yet was the
lack of documentation of Linux's async crypto API ;-)

A native driver could be used for
- kernel IPSec
- luks/dm-crypt
- ..

The cryptodev/cryptosoft interface is still needed for user space
applications such as OpenSSL. If those two parts where GPL licensed 
the acceptance for kernel inclusion could raise. Or do I forget
something important here?

Just my two cents worth :-)

bye,
Daniel

-- 
Daniel Mueller          http://www.danm.de
Berlin, Germany         OpenPGP: F9F982C1

Re: [Ocf-linux-users] OCF inbuilt and 2.6.27

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

Jivin inf...@he... lays it down ...
> Hello
> 
> I am sorry that just joining the mailing list and immediately sending a
> question is probably a great faux pas, and I want to apologize for that.

No need.

> My problem is related to the moving of OCF into the kernel with the 2.6.27 release.
> Before I was running 2.6.24-4 from the Slackware repository with the OCF
> 20080917 framework, but I was really excited about the OCF framework moving
> into the kernel with the 2.6.27 release.

OCF is not moving into the kernel,  not ever.  The licensing was one of
the major stumbing blocks.

My guess is that you are looking at the new cryptoAPI stuff in the
kernel which has hifn/talitos and other drivers.

> My problem is strange, but is the following... (please bare with me here,
> it might take a few lines to explain this)
> 
> After upgrading my development server to 2.6.27 with the inbuilt support for
> the HiFn 7956HXL luks have stopped working.
> To clarify what I mean by this. I can unlock my luks volumes just fine, but
> when the time comes to mount them, the mount command just hangs there
> forever, and I am forced to kill it.
> 
> I have tried the 2.6.27-7 from the Slackware repository, as well as the
> 2.6.28-7 from kernel.org, and the same behavior can be experienced. However,
> if I disable the HiFn card completely from the kernel I can mount my luks
> partitions just fine again.
> 
> Checking /proc/crypto I see that the HiFn modules are marked with a
> priority of 300 and the kernel inbuilt modules are marked with a priority
> of 100, and according to my broken logic (based on Cisco here) this should
> mean the kernel inbuilt modules should be used in preference for AES rather
> than my HiFn card.
> 
> I mainly bought this card because I am doing some development where I need
> literally shitloads of random entropy, and until the built in drivers I had
> no problems getting this, and the built in framework seems to give me even
> better RNG throughput, and I am really thankful for that! Don't get me wrong!
> 
> But is there any way of making both my HiFn card's RNG work as well as
> luks with a 2.6.27 kernel? Is anyone else but me experiencing the same
> issues with AES, HiFn, 2.6.27 and luks?

My guess is that previously you were using OCF for RNG entropy and not much
else,  while your luks was using software.

You get back to what you had by patching your kernel for OCF just as you
did in the past (although you need some patched posted to this list for
2.6.27), and disabling the kernel hifn driver.

Not sure if the RNG support is currently done by the in-kernel hifn
driver or not,  you would need to check the source.  OCF will still
support it as it always has, provising the kernel is appropriately
patched for OCF ;-)

Cheers,
Davidm

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

Re: [Ocf-linux-users] OCF inbuilt and 2.6.27

[<inf...@he...>]

Hello

I am sorry that just joining the mailing list and immediately sending a question is probably a great faux pas, and I want to apologize for that.

My problem is related to the moving of OCF into the kernel with the 2.6.27 release.
Before I was running 2.6.24-4 from the Slackware repository with the OCF 20080917 framework, but I was really excited about the OCF framework moving into the kernel with the 2.6.27 release.

My problem is strange, but is the following... (please bare with me here, it might take a few lines to explain this)

After upgrading my development server to 2.6.27 with the inbuilt support for the HiFn 7956HXL luks have stopped working.
To clarify what I mean by this. I can unlock my luks volumes just fine, but when the time comes to mount them, the mount command just hangs there forever, and I am forced to kill it.

I have tried the 2.6.27-7 from the Slackware repository, as well as the 2.6.28-7 from kernel.org, and the same behavior can be experienced. However, if I disable the HiFn card completely from the kernel I can mount my luks partitions just fine again.

Checking /proc/crypto I see that the HiFn modules are marked with a priority of 300 and the kernel inbuilt modules are marked with a priority of 100, and according to my broken logic (based on Cisco here) this should mean the kernel inbuilt modules should be used in preference for AES rather than my HiFn card.

I mainly bought this card because I am doing some development where I need literally shitloads of random entropy, and until the built in drivers I had no problems getting this, and the built in framework seems to give me even better RNG throughput, and I am really thankful for that! Don't get me wrong!

But is there any way of making both my HiFn card's RNG work as well as luks with a 2.6.27 kernel? Is anyone else but me experiencing the same issues with AES, HiFn, 2.6.27 and luks?

Best Regards,
Frode Moseng

 




"A word to the wise is infuriating." 
Hunter S. Thompson


-- 
_______________________________________________
Get your free email from http://europe.sanriotown.com