ocf-linux-users Mailing List for Open Cryptographic Framework for Linux (Page 11)
Brought to you by:
david-m
Menu
▾
▴
ocf-linux-users — Anything and everything ocf-linux related
You can subscribe to this list here.
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(12) |
Sep
(39) |
Oct
(16) |
Nov
(7) |
Dec
(17) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2008 |
Jan
(10) |
Feb
(1) |
Mar
(18) |
Apr
(8) |
May
(14) |
Jun
(12) |
Jul
(35) |
Aug
(11) |
Sep
(3) |
Oct
(3) |
Nov
(7) |
Dec
(2) |
| 2009 |
Jan
(20) |
Feb
(12) |
Mar
(31) |
Apr
(20) |
May
(31) |
Jun
|
Jul
(2) |
Aug
(5) |
Sep
(11) |
Oct
|
Nov
(2) |
Dec
(6) |
| 2010 |
Jan
(20) |
Feb
(10) |
Mar
(16) |
Apr
|
May
(17) |
Jun
|
Jul
(2) |
Aug
(30) |
Sep
(6) |
Oct
|
Nov
|
Dec
(1) |
| 2011 |
Jan
|
Feb
(9) |
Mar
(7) |
Apr
(6) |
May
(20) |
Jun
(2) |
Jul
(13) |
Aug
(4) |
Sep
(7) |
Oct
(9) |
Nov
(5) |
Dec
(2) |
| 2012 |
Jan
(5) |
Feb
(2) |
Mar
|
Apr
(1) |
May
|
Jun
(7) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(8) |
Dec
(19) |
| 2013 |
Jan
(2) |
Feb
(3) |
Mar
|
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2014 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(8) |
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
(2) |
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
| 2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
| 2022 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
|
Dec
|
|
From: mix.kao <mi...@ci...> - 2010-01-26 14:20:49
|
Hi there, I use OCF with ixp425 hardware acceleration (arm platform) and Openswan 2.6.24 and Linux kernel 2.6.28.10 When i start openswan daemon, it will auto load linux kernel crypto_algapi related kernel module, is it ok to use crypto in hardware? Or it means i still use software crypto? I try to rmmod all the crypto_algapi related module and try to build tunnel, it can build tunnel but can not ping each other. If i don't rmmod the crypto_algapi related module, the tunnel is work fine. So any suggestion to let openswan work with OCF and ixp4xx hardware crypto acceleration? Module Size Used by ecb 1152 0 cbc 1696 0 md5 3872 0 cryptomgr 71408 0 crypto_blkcipher 6468 3 ecb,cbc,cryptomgr aead 3200 1 cryptomgr des_generic 16128 0 crypto_algapi 7680 7 ecb,cbc,md5,cryptomgr,crypto_blkcipher,aead,des_generic ipsec 337716 2 ixp4xx 6992 0 cryptodev 9732 0 ocf 15304 2 ixp4xx,cryptodev nfnetlink_log 5064 1 nfnetlink 1528 2 nfnetlink_log iptable_filter 896 0 ip_tables 8080 1 iptable_filter ebtable_filter 768 1 ebtables 13504 1 ebtable_filter ipt_ULOG 3780 1 nf_nat_ftp 1216 0 nf_conntrack_ftp 4512 1 nf_nat_ftp nf_nat 9582 1 nf_nat_ftp xt_recent 4920 0 x_tables 7044 4 ip_tables,ebtables,ipt_ULOG,xt_recent ixp400_eth 16368 1 ixp400_oslinux 196804 2 ixp4xx,ixp400_eth loop 8908 2 Thanks a lot, Mix.K |
|
From: David M. <Dav...@se...> - 2010-01-13 05:15:36
|
Jivin mix.kao lays it down ... > Hi, there > > My platform is ARM IXP425 and using Linux kernel 2.6.28.10 with OCF > framework. > > I have compiled the ixp4xx.ko to support hardware crypto acceleration. > Now i am trying to do some test using "cryptotest" to make sure the > performance difference between software and hardware. > > Now i got a problem when i tried to use cryptosoft.ko. > When i load ocf.ko, cryptodev.ko, and cryptosoft.ko and run > cryptotest -a aes 256 8192 > cryptodev_open() > cryptodev_ioctl(cmd=c0046364 arg=bea4bb18) > cryptodev_ioctl(CRIOGET) > cryptodev_ioctl(cmd=c030636a arg=bea4bb6c) > cryptodev_ioctl(CIOCGSESSION2) > cryptodev_ioctl(CIOCGSESSION2) - no mac > crypto/ocf/crypto.c,370: DRIVER_LOCK() > crypto/ocf/crypto.c,406: DRIVER_UNLOCK() > cryptodev_ioctl(CIOCGSESSION2) - newsession 22 > cryptodev_ioctl(CIOCGSESSION2) - bail 22 > cryptodev_release() > > Anything i missing? Yes, see below. > # insmod ocf.ko crypto_debug=1 > crypto_init(0xbf0baf08) > crypto/ocf/crypto.c,1253: Q_LOCK() > crypto_proc - sleeping (qe=1 qb=0 kqe=1 kqb=0) > crypto/ocf/crypto.c,1400: Q_UNLOCK() > # insmod cryptodev.ko cryptodev_debug=1 > crypto/ocf/crypto.c,1441: RETQ_LOCK > crypto_ret_proc - sleeping > crypto/ocf/crypto.c,1472: RETQ_UNLOCK > cryptodev_init(bf0c4000) > # insmod cryptosoft.ko swcr_debug=1 > cryptosoft_init(bf0c831c) > crypto/ocf/crypto.c,483: DRIVER_LOCK() > crypto/ocf/crypto.c,528: DRIVER_UNLOCK() > cryptosoft_init:BLKCIPHER algorithm 1:'cbc(des)' not supported > cryptosoft_init:BLKCIPHER algorithm 2:'cbc(des3_ede)' not supported > cryptosoft_init:BLKCIPHER algorithm 3:'cbc(blowfish)' not supported > cryptosoft_init:BLKCIPHER algorithm 4:'cbc(cast5)' not supported > cryptosoft_init:BLKCIPHER algorithm 5:'cbc(skipjack)' not supported > cryptosoft_init:HMAC algorithm 6:'hmac(md5)' not supported > cryptosoft_init:HMAC algorithm 7:'hmac(sha1)' not supported > cryptosoft_init:HMAC algorithm 8:'hmac(ripemd160)' not supported > cryptosoft_init:HASH algorithm 9:'md5-kpdk??' not supported > cryptosoft_init:HASH algorithm 10:'sha1-kpdk??' not supported > cryptosoft_init:BLKCIPHER algorithm 11:'cbc(aes)' not supported > cryptosoft_init:BLKCIPHER algorithm 12:'ecb(arc4)' not supported > cryptosoft_init:HASH algorithm 13:'md5' not supported > cryptosoft_init:HASH algorithm 14:'sha1' not supported > cryptosoft_init:HMAC algorithm 15:'hmac(digest_null)' not supported > cryptosoft_init:BLKCIPHER algorithm 16:'cbc(cipher_null)' not supported > cryptosoft_init:COMP algorithm 17:'deflate' not supported > cryptosoft_init:HMAC algorithm 18:'hmac(sha256)' not supported > cryptosoft_init:HMAC algorithm 19:'hmac(sha384)' not supported > cryptosoft_init:HMAC algorithm 20:'hmac(sha512)' not supported > cryptosoft_init:BLKCIPHER algorithm 21:'cbc(camellia)' not supported > cryptosoft_init:HASH algorithm 22:'sha256' not supported > cryptosoft_init:HASH algorithm 23:'sha384' not supported > cryptosoft_init:HASH algorithm 24:'sha512' not supported > cryptosoft_init:HASH algorithm 25:'ripemd160' not supported cryptosoft uses the kernel cryptoAPI, so you need to enable the kernel cryptos AES/DES/etc in your kernel config in order to use cryptosoft. CONFIG_CRYPTO_DES=y CONFIG_CRYPTO_SHA1=y CONFIG_CRYPTO_AES=y CONFIG_CRYPTO_MD5=y CONFIG_CRYPTO_HMAC=y CONFIG_CRYPTO_CBC=y CONFIG_CRYPTO_HASH=y CONFIG_CRYPTO_SHA256=y CONFIG_CRYPTO_SHA512=y You can turn these off once you switch exclusively to the ixp4xx driver if you want to save some code in the kernel. Cheers, Davidm -- David McCullough, dav...@se..., Ph:+61 734352815 McAfee - SnapGear http://www.snapgear.com http://www.uCdot.org |
|
From: mix.kao <mi...@ci...> - 2010-01-13 03:53:55
|
Hi, there My platform is ARM IXP425 and using Linux kernel 2.6.28.10 with OCF framework. I have compiled the ixp4xx.ko to support hardware crypto acceleration. Now i am trying to do some test using "cryptotest" to make sure the performance difference between software and hardware. Now i got a problem when i tried to use cryptosoft.ko. When i load ocf.ko, cryptodev.ko, and cryptosoft.ko and run cryptotest -a aes 256 8192 cryptodev_open() cryptodev_ioctl(cmd=c0046364 arg=bea4bb18) cryptodev_ioctl(CRIOGET) cryptodev_ioctl(cmd=c030636a arg=bea4bb6c) cryptodev_ioctl(CIOCGSESSION2) cryptodev_ioctl(CIOCGSESSION2) - no mac crypto/ocf/crypto.c,370: DRIVER_LOCK() crypto/ocf/crypto.c,406: DRIVER_UNLOCK() cryptodev_ioctl(CIOCGSESSION2) - newsession 22 cryptodev_ioctl(CIOCGSESSION2) - bail 22 cryptodev_release() Anything i missing? # insmod ocf.ko crypto_debug=1 crypto_init(0xbf0baf08) crypto/ocf/crypto.c,1253: Q_LOCK() crypto_proc - sleeping (qe=1 qb=0 kqe=1 kqb=0) crypto/ocf/crypto.c,1400: Q_UNLOCK() # insmod cryptodev.ko cryptodev_debug=1 crypto/ocf/crypto.c,1441: RETQ_LOCK crypto_ret_proc - sleeping crypto/ocf/crypto.c,1472: RETQ_UNLOCK cryptodev_init(bf0c4000) # insmod cryptosoft.ko swcr_debug=1 cryptosoft_init(bf0c831c) crypto/ocf/crypto.c,483: DRIVER_LOCK() crypto/ocf/crypto.c,528: DRIVER_UNLOCK() cryptosoft_init:BLKCIPHER algorithm 1:'cbc(des)' not supported cryptosoft_init:BLKCIPHER algorithm 2:'cbc(des3_ede)' not supported cryptosoft_init:BLKCIPHER algorithm 3:'cbc(blowfish)' not supported cryptosoft_init:BLKCIPHER algorithm 4:'cbc(cast5)' not supported cryptosoft_init:BLKCIPHER algorithm 5:'cbc(skipjack)' not supported cryptosoft_init:HMAC algorithm 6:'hmac(md5)' not supported cryptosoft_init:HMAC algorithm 7:'hmac(sha1)' not supported cryptosoft_init:HMAC algorithm 8:'hmac(ripemd160)' not supported cryptosoft_init:HASH algorithm 9:'md5-kpdk??' not supported cryptosoft_init:HASH algorithm 10:'sha1-kpdk??' not supported cryptosoft_init:BLKCIPHER algorithm 11:'cbc(aes)' not supported cryptosoft_init:BLKCIPHER algorithm 12:'ecb(arc4)' not supported cryptosoft_init:HASH algorithm 13:'md5' not supported cryptosoft_init:HASH algorithm 14:'sha1' not supported cryptosoft_init:HMAC algorithm 15:'hmac(digest_null)' not supported cryptosoft_init:BLKCIPHER algorithm 16:'cbc(cipher_null)' not supported cryptosoft_init:COMP algorithm 17:'deflate' not supported cryptosoft_init:HMAC algorithm 18:'hmac(sha256)' not supported cryptosoft_init:HMAC algorithm 19:'hmac(sha384)' not supported cryptosoft_init:HMAC algorithm 20:'hmac(sha512)' not supported cryptosoft_init:BLKCIPHER algorithm 21:'cbc(camellia)' not supported cryptosoft_init:HASH algorithm 22:'sha256' not supported cryptosoft_init:HASH algorithm 23:'sha384' not supported cryptosoft_init:HASH algorithm 24:'sha512' not supported cryptosoft_init:HASH algorithm 25:'ripemd160' not supported cheers, Mix.K |
|
From: hiren j. <jos...@gm...> - 2010-01-08 06:01:34
|
Thank you David for the reply. Yes I know that IPCOMP is not an issue now. It was for 2.4.10+ and some early 2.6.x releases. Thank you for pointing to openswan-2.6.24rc5 . With #1004 solved, its now time for me to migrate (finally) :) Regards, Hiren On Fri, Jan 8, 2010 at 3:54 AM, David McCullough <Dav...@se...> wrote: > > Jivin hiren joshi lays it down ... >> Thank you David for the reply. >> Actually ocf-openswan-2.4.9-20070727.patch adds >> https://gsoc.xelerance.com/view.php?id=982 in openswan-2.4.9 and makes >> it unstable. >> >> However now I am migrating to KLIP-2.6.23 (only KLIPS from >> openswan-2.6.23) as it has OCF integrated. >> I don't see openswan-2.6.24rc5 on download page (http://openswan.org/code/). >> I hope openswan-2.6.23 will be stable enough. >> Migration of userspace code (pluto) will take some time for me - I am >> waiting for https://gsoc.xelerance.com/view.php?id=1004 to complete >> 100%. > > You can get early access to the releases here: > > http://www.openswan.org/download/development/ > > Both of the above are fixed AFAIK in this release: > > http://www.openswan.org/download/development/openswan-2.6.24rc5.tar.gz > > I have personally tested #1004 using klips and our automatic testing > here tests IPCOMP every night. I would be very interested if you still > encounter these problems. > > There is still one problem, tcpdump on klips interfaces is getting the data > offset wrong, but it doesn't seem to any more than that, > > Cheers, > Davidm > >> On Thu, Jan 7, 2010 at 5:28 PM, David McCullough >> <Dav...@se...> wrote: >> > >> > Jivin hiren joshi lays it down ... >> >> Hello, >> >> >> >> While looking at ocf-openswan-2.4.9-20070727.patch >> >> I found that besides OCF, the patch adds some non OCF things >> >> (like support for Dynamic DNS) in Openswan-2.4.9. >> >> >> >> As the patch is created via CVS, it adds things that are available >> >> in subsequent releases of Openswan. >> >> >> >> Can I have an OCF only patch for Openswan-2.4.9. >> > >> > Yes, ??just edit that patch to take out the bits you don't want :-) :-) >> > >> > The cvs is our local one (non-openswan) and there is no clean version. >> > Basically a lot of those features were implemented in our tree and then >> > pushed to mainline openswan. ??The only way I can help you is to hand edit >> > the patch. >> > >> > Is there any reason you cannot try openswan-2.6.24rc5 ? ??I think it is >> > pretty close to the functionality/stability of 2.4.9. >> > >> > To make it easier, ??you can get most of the benefit of OCF in openswan >> > by just taking the kernel changes in the patch. >> > >> > Cheers, >> > Davidm >> > >> > -- >> > David McCullough, ??dav...@se..., ??Ph:+61 734352815 >> > McAfee - SnapGear ??http://www.snapgear.com ?? ?? ?? ?? ?? ?? ?? ??http://www.uCdot.org >> > >> >> ------------------------------------------------------------------------------ >> This SF.Net email is sponsored by the Verizon Developer Community >> Take advantage of Verizon's best-in-class app development support >> A streamlined, 14 day to market process makes app distribution fast and easy >> Join now and get one step closer to millions of Verizon customers >> http://p.sf.net/sfu/verizon-dev2dev >> _______________________________________________ >> 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 > |
|
From: David M. <Dav...@se...> - 2010-01-07 22:24:25
|
Jivin hiren joshi lays it down ... > Thank you David for the reply. > Actually ocf-openswan-2.4.9-20070727.patch adds > https://gsoc.xelerance.com/view.php?id=982 in openswan-2.4.9 and makes > it unstable. > > However now I am migrating to KLIP-2.6.23 (only KLIPS from > openswan-2.6.23) as it has OCF integrated. > I don't see openswan-2.6.24rc5 on download page (http://openswan.org/code/). > I hope openswan-2.6.23 will be stable enough. > Migration of userspace code (pluto) will take some time for me - I am > waiting for https://gsoc.xelerance.com/view.php?id=1004 to complete > 100%. You can get early access to the releases here: http://www.openswan.org/download/development/ Both of the above are fixed AFAIK in this release: http://www.openswan.org/download/development/openswan-2.6.24rc5.tar.gz I have personally tested #1004 using klips and our automatic testing here tests IPCOMP every night. I would be very interested if you still encounter these problems. There is still one problem, tcpdump on klips interfaces is getting the data offset wrong, but it doesn't seem to any more than that, Cheers, Davidm > On Thu, Jan 7, 2010 at 5:28 PM, David McCullough > <Dav...@se...> wrote: > > > > Jivin hiren joshi lays it down ... > >> Hello, > >> > >> While looking at ocf-openswan-2.4.9-20070727.patch > >> I found that besides OCF, the patch adds some non OCF things > >> (like support for Dynamic DNS) in Openswan-2.4.9. > >> > >> As the patch is created via CVS, it adds things that are available > >> in subsequent releases of Openswan. > >> > >> Can I have an OCF only patch for Openswan-2.4.9. > > > > Yes, ??just edit that patch to take out the bits you don't want :-) :-) > > > > The cvs is our local one (non-openswan) and there is no clean version. > > Basically a lot of those features were implemented in our tree and then > > pushed to mainline openswan. ??The only way I can help you is to hand edit > > the patch. > > > > Is there any reason you cannot try openswan-2.6.24rc5 ? ??I think it is > > pretty close to the functionality/stability of 2.4.9. > > > > To make it easier, ??you can get most of the benefit of OCF in openswan > > by just taking the kernel changes in the patch. > > > > Cheers, > > Davidm > > > > -- > > David McCullough, ??dav...@se..., ??Ph:+61 734352815 > > McAfee - SnapGear ??http://www.snapgear.com ?? ?? ?? ?? ?? ?? ?? ??http://www.uCdot.org > > > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > 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 |
|
From: David M. <Dav...@se...> - 2010-01-07 22:18:54
|
Jivin mix.kao lays it down ... > Thanks David, > > So can i say if i need the IXP425 hardward crypto acceleration support > I have two choices: > > 1. Try to use the native IXP crypto that linux kernel 2.6.31 provided > and use openswan as user space tool without KLIPS support? Yes. > 2. Try to compile the openswan-2.6.24rc5 using KLIPS and no need kernel > patch provided by OCF group. You need the OCD patch for the kernel, you just don't need to patch openswan. Sorry for the confusion. > Another question: > I patched the 2.6.31 kernel with OCF, when i enabled the CONFIG_OCF_IXP4XX=m > I got many compile errors when built OCF_IXP4XX. > Is there anyone has any suggestion or anything i should prepare before > compile the IXP4XX kernel module? Do you have the Intel IXP access library ? The ixp4xx OCF driver needs it. You may need to adjust the Makefile in the ixp4xx directory to point to your access library. Cheers, Davidm > On 01/07/2010 07:54 PM, David McCullough wrote: > > > > Jivin mix.kao lays it down ... > >> Hi there, > >> > >> sorry for bothering, i have some questions need your help. > >> > >> 1. My platform is ARM with IXP425, can OCF, Openswan, and Linux kernel > >> 2.6.31 with native IPSec stack support IXP425 crypto hardware > >> acceleration? Or i have to use Openswan with KLIPS patch in kernel? > > > > netkey (native ipsec stack) will not use OCF. There is native IXP > > crypto in 2.6.31. I have't used it but we are looking at trying it out > > soon. > > > > For OCF, use the latest openswan-2.6.24rc5 from openswan.org and you > > shouldn't have to patch your kernel. > > > >> 2. I have patched the OCF into Linux kernel, if i want to use IXP425 > >> hardware crypto acceleration, what kernel options should i enable? > >> Attached screen shot is my kernel OCF config, is it correct or what > >> options should i select? > > > > The related options I run are: > > > > CONFIG_KLIPS=m > > CONFIG_KLIPS_ESP=y > > CONFIG_KLIPS_AH=y > > # CONFIG_KLIPS_AUTH_HMAC_MD5 is not set > > # CONFIG_KLIPS_AUTH_HMAC_SHA1 is not set > > # CONFIG_KLIPS_ALG is not set > > # CONFIG_KLIPS_ENC_3DES is not set > > CONFIG_KLIPS_IPCOMP=y > > CONFIG_KLIPS_OCF=y > > CONFIG_KLIPS_DEBUG=y > > CONFIG_KLIPS_IF_MAX=4 > > CONFIG_OCF_OCF=m > > # CONFIG_OCF_RANDOMHARVEST is not set > > CONFIG_OCF_CRYPTODEV=m > > # CONFIG_OCF_CRYPTOSOFT is not set > > # CONFIG_OCF_SAFE is not set > > CONFIG_OCF_IXP4XX=m > > # CONFIG_OCF_IXP4XX_SHA1_MD5 is not set > > # CONFIG_OCF_HIFN is not set > > # CONFIG_OCF_HIFNHIPP is not set > > # CONFIG_OCF_TALITOS is not set > > # CONFIG_OCF_EP80579 is not set > > # CONFIG_OCF_CRYPTOCTEON is not set > > # CONFIG_OCF_OCFNULL is not set > > # CONFIG_OCF_BENCH is not set > > > > Cheers, > > Davidm > > > > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > 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 |
|
From: hiren j. <jos...@gm...> - 2010-01-07 16:28:16
|
Thank you David for the reply. Actually ocf-openswan-2.4.9-20070727.patch adds https://gsoc.xelerance.com/view.php?id=982 in openswan-2.4.9 and makes it unstable. However now I am migrating to KLIP-2.6.23 (only KLIPS from openswan-2.6.23) as it has OCF integrated. I don't see openswan-2.6.24rc5 on download page (http://openswan.org/code/). I hope openswan-2.6.23 will be stable enough. Migration of userspace code (pluto) will take some time for me - I am waiting for https://gsoc.xelerance.com/view.php?id=1004 to complete 100%. Thanks for your time. Regards, Hiren On Thu, Jan 7, 2010 at 5:28 PM, David McCullough <Dav...@se...> wrote: > > Jivin hiren joshi lays it down ... >> Hello, >> >> While looking at ocf-openswan-2.4.9-20070727.patch >> I found that besides OCF, the patch adds some non OCF things >> (like support for Dynamic DNS) in Openswan-2.4.9. >> >> As the patch is created via CVS, it adds things that are available >> in subsequent releases of Openswan. >> >> Can I have an OCF only patch for Openswan-2.4.9. > > Yes, just edit that patch to take out the bits you don't want :-) :-) > > The cvs is our local one (non-openswan) and there is no clean version. > Basically a lot of those features were implemented in our tree and then > pushed to mainline openswan. The only way I can help you is to hand edit > the patch. > > Is there any reason you cannot try openswan-2.6.24rc5 ? I think it is > pretty close to the functionality/stability of 2.4.9. > > To make it easier, you can get most of the benefit of OCF in openswan > by just taking the kernel changes in the patch. > > Cheers, > Davidm > > -- > David McCullough, dav...@se..., Ph:+61 734352815 > McAfee - SnapGear http://www.snapgear.com http://www.uCdot.org > |
|
From: mix.kao <mi...@ci...> - 2010-01-07 13:04:29
|
Thanks David, So can i say if i need the IXP425 hardward crypto acceleration support I have two choices: 1. Try to use the native IXP crypto that linux kernel 2.6.31 provided and use openswan as user space tool without KLIPS support? 2. Try to compile the openswan-2.6.24rc5 using KLIPS and no need kernel patch provided by OCF group. Another question: I patched the 2.6.31 kernel with OCF, when i enabled the CONFIG_OCF_IXP4XX=m I got many compile errors when built OCF_IXP4XX. Is there anyone has any suggestion or anything i should prepare before compile the IXP4XX kernel module? best regards. On 01/07/2010 07:54 PM, David McCullough wrote: > > Jivin mix.kao lays it down ... >> Hi there, >> >> sorry for bothering, i have some questions need your help. >> >> 1. My platform is ARM with IXP425, can OCF, Openswan, and Linux kernel >> 2.6.31 with native IPSec stack support IXP425 crypto hardware >> acceleration? Or i have to use Openswan with KLIPS patch in kernel? > > netkey (native ipsec stack) will not use OCF. There is native IXP > crypto in 2.6.31. I have't used it but we are looking at trying it out > soon. > > For OCF, use the latest openswan-2.6.24rc5 from openswan.org and you > shouldn't have to patch your kernel. > >> 2. I have patched the OCF into Linux kernel, if i want to use IXP425 >> hardware crypto acceleration, what kernel options should i enable? >> Attached screen shot is my kernel OCF config, is it correct or what >> options should i select? > > The related options I run are: > > CONFIG_KLIPS=m > CONFIG_KLIPS_ESP=y > CONFIG_KLIPS_AH=y > # CONFIG_KLIPS_AUTH_HMAC_MD5 is not set > # CONFIG_KLIPS_AUTH_HMAC_SHA1 is not set > # CONFIG_KLIPS_ALG is not set > # CONFIG_KLIPS_ENC_3DES is not set > CONFIG_KLIPS_IPCOMP=y > CONFIG_KLIPS_OCF=y > CONFIG_KLIPS_DEBUG=y > CONFIG_KLIPS_IF_MAX=4 > CONFIG_OCF_OCF=m > # CONFIG_OCF_RANDOMHARVEST is not set > CONFIG_OCF_CRYPTODEV=m > # CONFIG_OCF_CRYPTOSOFT is not set > # CONFIG_OCF_SAFE is not set > CONFIG_OCF_IXP4XX=m > # CONFIG_OCF_IXP4XX_SHA1_MD5 is not set > # CONFIG_OCF_HIFN is not set > # CONFIG_OCF_HIFNHIPP is not set > # CONFIG_OCF_TALITOS is not set > # CONFIG_OCF_EP80579 is not set > # CONFIG_OCF_CRYPTOCTEON is not set > # CONFIG_OCF_OCFNULL is not set > # CONFIG_OCF_BENCH is not set > > Cheers, > Davidm > |
|
From: David M. <Dav...@se...> - 2010-01-07 11:58:39
|
Jivin hiren joshi lays it down ... > Hello, > > While looking at ocf-openswan-2.4.9-20070727.patch > I found that besides OCF, the patch adds some non OCF things > (like support for Dynamic DNS) in Openswan-2.4.9. > > As the patch is created via CVS, it adds things that are available > in subsequent releases of Openswan. > > Can I have an OCF only patch for Openswan-2.4.9. Yes, just edit that patch to take out the bits you don't want :-) :-) The cvs is our local one (non-openswan) and there is no clean version. Basically a lot of those features were implemented in our tree and then pushed to mainline openswan. The only way I can help you is to hand edit the patch. Is there any reason you cannot try openswan-2.6.24rc5 ? I think it is pretty close to the functionality/stability of 2.4.9. To make it easier, you can get most of the benefit of OCF in openswan by just taking the kernel changes in the patch. Cheers, Davidm -- David McCullough, dav...@se..., Ph:+61 734352815 McAfee - SnapGear http://www.snapgear.com http://www.uCdot.org |
|
From: David M. <Dav...@se...> - 2010-01-07 11:54:27
|
Jivin mix.kao lays it down ... > Hi there, > > sorry for bothering, i have some questions need your help. > > 1. My platform is ARM with IXP425, can OCF, Openswan, and Linux kernel > 2.6.31 with native IPSec stack support IXP425 crypto hardware > acceleration? Or i have to use Openswan with KLIPS patch in kernel? netkey (native ipsec stack) will not use OCF. There is native IXP crypto in 2.6.31. I have't used it but we are looking at trying it out soon. For OCF, use the latest openswan-2.6.24rc5 from openswan.org and you shouldn't have to patch your kernel. > 2. I have patched the OCF into Linux kernel, if i want to use IXP425 > hardware crypto acceleration, what kernel options should i enable? > Attached screen shot is my kernel OCF config, is it correct or what > options should i select? The related options I run are: CONFIG_KLIPS=m CONFIG_KLIPS_ESP=y CONFIG_KLIPS_AH=y # CONFIG_KLIPS_AUTH_HMAC_MD5 is not set # CONFIG_KLIPS_AUTH_HMAC_SHA1 is not set # CONFIG_KLIPS_ALG is not set # CONFIG_KLIPS_ENC_3DES is not set CONFIG_KLIPS_IPCOMP=y CONFIG_KLIPS_OCF=y CONFIG_KLIPS_DEBUG=y CONFIG_KLIPS_IF_MAX=4 CONFIG_OCF_OCF=m # CONFIG_OCF_RANDOMHARVEST is not set CONFIG_OCF_CRYPTODEV=m # CONFIG_OCF_CRYPTOSOFT is not set # CONFIG_OCF_SAFE is not set CONFIG_OCF_IXP4XX=m # CONFIG_OCF_IXP4XX_SHA1_MD5 is not set # CONFIG_OCF_HIFN is not set # CONFIG_OCF_HIFNHIPP is not set # CONFIG_OCF_TALITOS is not set # CONFIG_OCF_EP80579 is not set # CONFIG_OCF_CRYPTOCTEON is not set # CONFIG_OCF_OCFNULL is not set # CONFIG_OCF_BENCH is not set Cheers, Davidm -- David McCullough, dav...@se..., Ph:+61 734352815 McAfee - SnapGear http://www.snapgear.com http://www.uCdot.org |
|
From: mix.kao <mi...@ci...> - 2010-01-07 06:32:32
|
Hi there, sorry for bothering, i have some questions need your help. 1. My platform is ARM with IXP425, can OCF, Openswan, and Linux kernel 2.6.31 with native IPSec stack support IXP425 crypto hardware acceleration? Or i have to use Openswan with KLIPS patch in kernel? 2. I have patched the OCF into Linux kernel, if i want to use IXP425 hardware crypto acceleration, what kernel options should i enable? Attached screen shot is my kernel OCF config, is it correct or what options should i select? Thanks a lots |
|
From: mix.kao <mi...@ci...> - 2010-01-07 06:22:30
|
Hi there, sorry for bothering, i have some questions need your help. 1. My platform is ARM with IXP425, can OCF, Openswan, and Linux kernel 2.6.31 with native IPSec stack support IXP425 crypto hardware acceleration? Or i have to use Openswan with KLIPS patch in kernel? 2. I have patched the OCF into Linux kernel, if i want to use IXP425 hardware crypto acceleration, what kernel options should i enable? Attached screen shot is my kernel OCF config, is it correct or what options should i select? Thanks a lots |
|
From: hiren j. <jos...@gm...> - 2009-12-29 16:45:23
|
Hello, While looking at ocf-openswan-2.4.9-20070727.patch I found that besides OCF, the patch adds some non OCF things (like support for Dynamic DNS) in Openswan-2.4.9. As the patch is created via CVS, it adds things that are available in subsequent releases of Openswan. Can I have an OCF only patch for Openswan-2.4.9. Thank you for your time. Regards, Hiren |
|
From: Peter F. <pe...@we...> - 2009-12-14 21:32:28
|
And a patch for openssl-0.9.8k (please forgive the misleading file name) On Mon, Dec 14, 2009 at 3:19 PM, Peter Fry <pe...@we...> wrote: > Hello everyone, attached is a patch for linux 2.6.31 to fix the > problem with find_task_by_vpid() no longer being exported. This did > cause a licensing issue, since find_vpid() isn't compatible with a > pure BSD license. I modified the license string for crypto.c to change > the license to GPL/BSD to allow the kernel to compile, although I'm > not sure if this is the preferred solution for this project. I'm > working on the assumption that because it is a linux specific project > that the licensing issue will get resolved somehow. > > Regards, > Peter > -- 831-920-4594 |
|
From: Peter F. <pe...@we...> - 2009-12-14 20:44:43
|
Hello everyone, attached is a patch for linux 2.6.31 to fix the problem with find_task_by_vpid() no longer being exported. This did cause a licensing issue, since find_vpid() isn't compatible with a pure BSD license. I modified the license string for crypto.c to change the license to GPL/BSD to allow the kernel to compile, although I'm not sure if this is the preferred solution for this project. I'm working on the assumption that because it is a linux specific project that the licensing issue will get resolved somehow. Regards, Peter |
|
From: Philipp W. <fli...@gm...> - 2009-12-14 14:22:19
|
Hey, Im searching for a openssl patch that supports the current version eq 0.9.8L The current ocf-linux tarball contains only patches for e,i and g. thanks flip |
|
From: David M. <Dav...@se...> - 2009-12-13 23:32:04
|
Jivin Mark Gillespie lays it down ... > Hi, I have a marvel kirkwood based Sheevaplug, and kernel 2.6.32 brings a > new crypto hardware driver "mv_cesa". I have patched my kernel with the > latest ocf-linux patch over kernel 2.6.32, and it applied cleanly, aside > from a few line offsets, the kernel boots, and I have a /dev/crypto. > I have compiled cryptotest and it runs, but does not seem to to use the > mv_cesa driver. The mv_cesa driver in 2.6.32 is a kernel cryptoapi driver and not an OCF driver. AFAIK is currently only supports AES and not all the ciphers/hashses and AEAD interfaces that you may want. Currently I think it's primary purpose is dm-crypt. In order for OCF to use that driver you will need to use the OCF cryptosoft driver, and it will need to be modified to handle the ASYNC Crypto-API interface as well as the sync interface it currently uses. The other option is to use the OCF native driver that Marvell wrote. It performs well. You will need to turn off the mv_cesa driver if you do that though, they will not be compatible. Not sure where you get this exactly, but I think it comes with their 2.6.22 kernel. > Does the ocf-linux patch need to be aware of the driver? Are there any > updated patches that include this? Is it easy to hack it myself? We have 2.6.32 running on a Marvell 88f6281 here and are working on the changes needed, but they could be a few weeks out yet based on silly season time lines and holidays :-) It's not completely trivial and is made somewhat harder by the sparse doc for the cryptoapi in the kernel. > PS. There is a discussion about this here: http://plugcomputer.org/plugforum/index.php?topic=1014.msg6588#msg6588 Feel free to pass on any info you want to share with the group, Cheers, Davidm -- David McCullough, dav...@se..., Ph:+61 734352815 McAfee - SnapGear http://www.snapgear.com http://www.uCdot.org |
|
From: Mark G. <ocf...@ma...> - 2009-12-13 14:31:38
|
Hi, I have a marvel kirkwood based Sheevaplug, and kernel 2.6.32 brings a new crypto hardware driver "mv_cesa". I have patched my kernel with the latest ocf-linux patch over kernel 2.6.32, and it applied cleanly, aside from a few line offsets, the kernel boots, and I have a /dev/crypto. I have compiled cryptotest and it runs, but does not seem to to use the mv_cesa driver. Does the ocf-linux patch need to be aware of the driver? Are there any updated patches that include this? Is it easy to hack it myself? Many thanks. PS. There is a discussion about this here: http://plugcomputer.org/plugforum/index.php?topic=1014.msg6588#msg6588 -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ |
|
From: David M. <Dav...@se...> - 2009-11-09 22:33:57
|
Jivin hiren joshi lays it down ... > Hello, > > A quick look at the code told me that Openswan/KLIPS is inherently > synchronous and the OCF patch makes it asynchronous. > Am I right? Yes, that is true of 2.4 series openswan, but openswan 2.6.X where X is anything almost has the OCF patches fully integrated and maintained. I would recommend using openswna 2.6.24rc2 or later at this point, Cheers, Davidm -- David McCullough, dav...@se..., Ph:+61 734352815 McAfee - SnapGear http://www.snapgear.com http://www.uCdot.org |
|
From: hiren j. <jos...@gm...> - 2009-11-09 16:04:08
|
Hello, A quick look at the code told me that Openswan/KLIPS is inherently synchronous and the OCF patch makes it asynchronous. Am I right? Thanks for your time, Regards, Hiren |
|
From: David M. <Dav...@se...> - 2009-09-17 11:41:49
|
Hi all, Patch below for use on newer kernels where IRQ_NONE and co became an enum instead of an ifdef. This stops the kernel trapping due to bad IRQ handling on shared interrupts with OCF HW drivers. Cheers, Davidm Index: modules/ocf/ocf-compat.h =================================================================== RCS file: ocf/ocf-compat.h,v retrieving revision 1.12 diff -u -r1.12 ocf-compat.h --- modules/ocf/ocf-compat.h 12 Aug 2009 00:52:25 -0000 1.12 +++ modules/ocf/ocf-compat.h 17 Sep 2009 00:45:32 -0000 @@ -191,10 +191,14 @@ /* older kernels don't have these */ -#ifndef IRQ_NONE +#include <asm/irq.h> +#if !defined(IRQ_NONE) && !defined(IRQ_RETVAL) #define IRQ_NONE #define IRQ_HANDLED +#define IRQ_WAKE_THREAD +#define IRQ_RETVAL #define irqreturn_t void +typedef irqreturn_t (*irq_handler_t)(int irq, void *arg, struct pt_regs *regs); #endif #ifndef IRQF_SHARED #define IRQF_SHARED SA_SHIRQ -- David McCullough, dav...@se..., Ph:+61 734352815 McAfee - SnapGear http://www.snapgear.com http://www.uCdot.org |
|
From: Kim P. <kim...@fr...> - 2009-09-15 23:15:12
|
On Fri, 11 Sep 2009 10:37:00 EDT Job...@ao... wrote: > I am running Linux 2.6.26 on an MPC8248. I patched my kernel with the > ocf-linux-26-20080917 patch and my openssl-0.9.8e with the corresponding > patch. I am going to modify crypto/ocf/talitos/talitos.c to support SEC1. drivers/crypto/talitos.c is a better way to go, IMO. > Should CONFIG__PPC_MERGE be set? How does one set it? I can't find any > reference to it when I make menuconfig. this is completely off-topic here (please use linuxppc-dev list for powerpc-specific questions in the future), but: PPC_MERGE was a temporary define to assist the powerpc ARCH transition from ARCH=ppc to ARCH=powerpc. One would #ifdef PPC_MERGE for the new code, and the opposite for the old, outgoing code to keep things working in the interim. Kim |
|
From: <Job...@ao...> - 2009-09-11 14:37:13
|
I am running Linux 2.6.26 on an MPC8248. I patched my kernel with the ocf-linux-26-20080917 patch and my openssl-0.9.8e with the corresponding patch. I am going to modify crypto/ocf/talitos/talitos.c to support SEC1. Should CONFIG__PPC_MERGE be set? How does one set it? I can't find any reference to it when I make menuconfig. |
|
From: <Job...@ao...> - 2009-09-11 14:01:10
|
So none of the Talitos drivers support SEC1? I thought crypto/ocf/talitos/talitos.c supported SEC1 since the MPC8248 and SEC1 is mentioned in the header of that file. I'll have to use the code from the standalone SEC1 driver on the Freescale website and modify Talitos for SEC1 support, right? In a message dated 9/10/2009 4:18:04 P.M. Pacific Daylight Time, kim...@fr... writes: On Wed, 9 Sep 2009 18:47:11 -0700 job...@ao... wrote: > > I am running Linux 2.6.26 on an MPC8248. I patched my kernel with the 8248 has a v.1.x SEC h/w, whereas the talitos driver currently is compatible with SEC versions 2.0+. > > the ocf-linux-26-20080917 patch and my openssl-0.9.8e with the > > corresponding patch. When I ran cryptotest, I got results for > > various algorithms and thought I was using the Freescale SEC. In > > crypto/ocf/talitos/talitos.c, I put in some printk's and set > > talitos_debug to 1 to verify that the Freescale SEC was being used > > to do the encryption. > > > > Nothing was printed. So, apparently it is not being used. Is this > > a configuration issue? My .config file follows. Do I have > > something incorrectly configured for the Freescale SEC to be utilized? even if you convince your configuration to enable the driver (for example one would presumably provide a device tree node for ARCH=powerpc that would fake SEC2.0 compatibility), the talitos driver would need to be extended to support: o the SEC1.x ring buffer (it doesn't use fetch FIFOs like the SEC2.0+) o I don't believe the SEC1.x can do the cipher+hash, e.g. for IPsec, in one pass. I.e., there is no ipsec_esp descriptor. One would have to split the fn into two descriptor submissions to satisfy this type of request. o the registers and bit positions within the registers may vary for SEC1.x->SEC2.x, depending on the part. hth, Kim p.s. the upsteam kernel driver, drivers/crypto/talitos.c is in the same boat wrt SEC1.x support - sorry. |
|
From: Kim P. <kim...@fr...> - 2009-09-10 23:18:20
|
On Wed, 9 Sep 2009 18:47:11 -0700 job...@ao... wrote: > > I am running Linux 2.6.26 on an MPC8248. I patched my kernel with the 8248 has a v.1.x SEC h/w, whereas the talitos driver currently is compatible with SEC versions 2.0+. > > the ocf-linux-26-20080917 patch and my openssl-0.9.8e with the > > corresponding patch. When I ran cryptotest, I got results for > > various algorithms and thought I was using the Freescale SEC. In > > crypto/ocf/talitos/talitos.c, I put in some printk's and set > > talitos_debug to 1 to verify that the Freescale SEC was being used > > to do the encryption. > > > > Nothing was printed. So, apparently it is not being used. Is this > > a configuration issue? My .config file follows. Do I have > > something incorrectly configured for the Freescale SEC to be utilized? even if you convince your configuration to enable the driver (for example one would presumably provide a device tree node for ARCH=powerpc that would fake SEC2.0 compatibility), the talitos driver would need to be extended to support: o the SEC1.x ring buffer (it doesn't use fetch FIFOs like the SEC2.0+) o I don't believe the SEC1.x can do the cipher+hash, e.g. for IPsec, in one pass. I.e., there is no ipsec_esp descriptor. One would have to split the fn into two descriptor submissions to satisfy this type of request. o the registers and bit positions within the registers may vary for SEC1.x->SEC2.x, depending on the part. hth, Kim p.s. the upsteam kernel driver, drivers/crypto/talitos.c is in the same boat wrt SEC1.x support - sorry. |
4 messages has been excluded from this view by a project administrator.
