ocf-linux-users Mailing List for Open Cryptographic Framework for Linux (Page 19)
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: David M. <Dav...@se...> - 2008-07-09 23:02:31
|
Jivin Andreas Steinel lays it down ... > Hi all, > > One month ago, Nikola Ciprich asked if it's possible to enhance the > throughput of openVPN connections via OCF. Are there any new > information of known tweaks for this problem? > > I'd the problem too. Maybe it could help if someone has any idea to > implement it in openvpn an can explain it here. I haven't looked at it, but does OpenVPN use openssl for it's crypto ? If it does just apply the ocf patch to your openssl dist before building and add te hconfigure options --with-cryptodev to enable OCF support. If OpenVPN doesn't use OpenSSL then it should be easy to look at the openswan (pluto) patch or the cryptotest tool to see how to call into cryptodev to make things faster, Cheers, Davidm -- David McCullough, dav...@se..., Ph:+61 734352815 Secure Computing - SnapGear http://www.uCdot.org http://www.snapgear.com |
|
From: David M. <Dav...@se...> - 2008-07-09 22:57:38
|
Jivin Manish RATHI lays it down ... > Hi, > As per my understandning ipsec in linux kernel uses linux kernel crypto > not OCF framework? That is right. > Is there any work done for this? The klips stack in openswan has been fully accelerated by OCF for some time now. So if you plan to use openswan for your keying daemon there is very little to do to use klips as well, Cheers, Davidm -- David McCullough, dav...@se..., Ph:+61 734352815 Secure Computing - SnapGear http://www.uCdot.org http://www.snapgear.com |
|
From: Adam C. (Le_Vert) <ga...@le...> - 2008-07-09 18:00:53
|
David McCullough a écrit : > Jivin "Adam Cécile (Le_Vert)" lays it down ... > >> Daniel Mueller a écrit : >> >>> On Mon, 02 Jun 2008 17:25:23 +0200 Adam Cécile wrote: >>> >>> I do not own a AMD Geode but.. >>> >>> >>> >>>> Loaded kernel modules: >>>> gandalf@alix:~$ lsmod | grep -e cry -e oc >>>> cryptodev 13988 3 >>>> crypto_null 2624 0 >>>> cryptosoft 12136 0 >>>> ocf 28984 2 cryptodev,cryptosoft >>>> >>>> >>> .. you need to load the geode-aes module as well. You can find it in >>> your kernel configuration. >>> >>> Cryptographic API ---> >>> [*] Hardware crypto devices ---> >>> <M> Support for the Geode LX AES engine >>> >>> Try to load the modules in the following order: >>> geode-aes.ko >>> ocf.ko >>> cryptosoft.ko >>> cryptodev.ko >>> >>> bye, >>> danm >>> >>> >>> >> gandalf@alix:~$ cat /etc/modules >> # /etc/modules: kernel modules to load at boot time. >> # >> # This file contains the names of kernel modules that should be loaded >> # at boot time, one per line. Lines beginning with "#" are ignored. >> >> # Geode WatchDog >> geodewdt >> >> # Geode LX AES hardware crypto >> geode-aes >> geode-rng >> ocf >> cryptosoft >> cryptodev >> >> # Alix LEDs driver >> leds-alix >> >> # Sensors >> lm90 >> >> It's already loaded. Any other idea ? ;) >> > > Did you check that with a "lsmod" to be sure ? > > Thanks, > Davidm > > Hello, I've updated to debian's kernel 2.6.25-3-686 + latest ocf patch and I still don't see any performance improvement. gandalf@wrap:~$ lsmod | grep -e cry -e oc cryptodev 13572 3 crypto_null 3392 0 cryptosoft 11624 0 ocf 29176 2 cryptodev,cryptosoft crypto_blkcipher 18564 4 crypto_null,ecb,cbc,geode_aes dock 10320 1 libata gandalf@wrap:~$ ls -lah /dev/crypto crw-rw-rw- 1 root root 10, 70 Jan 1 2000 /dev/crypto gandalf@wrap:~$ openssl engine (cryptodev) BSD cryptodev engine (padlock) VIA PadLock (no-RNG, no-ACE) (dynamic) Dynamic engine loading support gandalf@wrap:~$ openssl speed -evp aes128 -elapsed 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 aes-128-cbc for 3s on 16 size blocks: 123525 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 64 size blocks: 119105 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 256 size blocks: 103091 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 1024 size blocks: 68212 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 2048 size blocks: 46401 aes-128-cbc's in 3.00s OpenSSL 0.9.8g 19 Oct 2007 built on: Mon Jun 2 14:52:51 UTC 2008 options:bn(64,32) md2(int) rc4(idx,int) des(ptr,risc1,16,long) aes(partial) blowfish(idx) compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DHAVE_CRYPTODEV -DL_ENDIAN -DTERMIO -O3 -march=i586 -Wa,--noexecstack -g -Wall -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DSHA1_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM available timing options: TIMES TIMEB HZ=100 [sysconf value] timing function used: ftime The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 2048 bytes aes-128-cbc 658.80k 2540.91k 8797.10k 23283.03k 31676.42k gandalf@wrap:~$ openssl speed -evp aes128 -elapsed -engine cryptodev 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 aes-128-cbc for 3s on 16 size blocks: 123212 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 64 size blocks: 119413 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 256 size blocks: 103493 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 1024 size blocks: 67906 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 2048 size blocks: 46018 aes-128-cbc's in 3.00s OpenSSL 0.9.8g 19 Oct 2007 built on: Mon Jun 2 14:52:51 UTC 2008 options:bn(64,32) md2(int) rc4(idx,int) des(ptr,risc1,16,long) aes(partial) blowfish(idx) compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DHAVE_CRYPTODEV -DL_ENDIAN -DTERMIO -O3 -march=i586 -Wa,--noexecstack -g -Wall -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DSHA1_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM available timing options: TIMES TIMEB HZ=100 [sysconf value] timing function used: ftime The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 2048 bytes aes-128-cbc 657.13k 2546.63k 8831.40k 23178.58k 31414.95k Only OpenSSL hasn't been rebuilt with latest OCF patch but I'll do asap. Any pointers would be greatly appreciated (maybe my bench commands are just wrong ?). Regards, Adam. |
|
From: Vrabete, B. <bra...@in...> - 2008-07-09 14:51:03
|
--------------------------------------------------------------------- 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. |
|
From: Manish R. <man...@st...> - 2008-07-09 09:46:26
|
Hi, ipsec in vannila linux kernel uses linux kernel crypto not OCF framework? I am using OCF driver for crypto acceleration to be used with openssl engine. Currently ipsec uses linux kernel crypto framework. So I've to write 2 drivers 1) kernel crypto driver 2) OCF driver I'd like to use single driver that can be used with OpenSSL/OCF and Linux kernel crypto. Is there any stable patch available for ipsec in latest linux kernel so that it uses OCF? Why OCF is not used in linux kernel for ipsec? I've read that current ipsec doesn't uses Bottom half so async API framework such as OCF is not required. Is it correct? What are the pros and cons of using OCF with ipsec? Regards Manish |
|
From: Andreas S. <a.s...@go...> - 2008-07-09 08:20:18
|
Hi all, One month ago, Nikola Ciprich asked if it's possible to enhance the throughput of openVPN connections via OCF. Are there any new information of known tweaks for this problem? I'd the problem too. Maybe it could help if someone has any idea to implement it in openvpn an can explain it here. Best, Andreas |
|
From: Andreas S. <a.s...@go...> - 2008-07-09 08:17:20
|
Hi David, That was the trick. Now the encryption is approx. 100 times faster. Thanks Andreas On Fri, Jul 4, 2008 at 4:08 PM, David McCullough <Dav...@se...> wrote: > > Jivin Andreas Steinel lays it down ... >> Hi everybody, >> >> I tried todays version 20080704 and doesn't get it work. Here a detailed list: >> * Debian Etch (4.0) running on Soekris 5501 with AMD Geode >> * Kernel running 2.6.25.10-soekris #6 Fri Jul 4 15:53:42 CEST 2008 >> i586 GNU/Linux >> * Modules compiled and running: >> Module Size Used by >> cryptodev 13572 0 >> ocf 27764 1 cryptodev >> geode_aes 6628 0 > > It is proabbly because you have no OCF crypto drivers installed. You need > to load cryptosoft to take advantage of the in kernel geode driver. If > it doesn't work let us know, > > Cheers, > Davidm > >> * openssl is compiled and cryptodev can be choosen as engine, but no >> change to dynamic >> * cryptotest doesn't work: >> # ./cryptotest -v -a aes >> crid = 3000000 >> cipher aes keylen 16 >> CIOCGSESSION: Invalid argument >> >> Any ideas? >> >> Best >> Andreas >> >> ------------------------------------------------------------------------- >> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! >> Studies have shown that voting for your favorite open source project, >> along with a healthy diet, reduces your potential for chronic lameness >> and boredom. Vote Now at http://www.sourceforge.net/community/cca08 >> _______________________________________________ >> Ocf-linux-users mailing list >> Ocf...@li... >> https://lists.sourceforge.net/lists/listinfo/ocf-linux-users >> > > -- > David McCullough, dav...@se..., Ph:+61 734352815 > Secure Computing - SnapGear http://www.uCdot.org http://www.snapgear.com > |
|
From: Manish R. <man...@st...> - 2008-07-09 06:28:27
|
Hi, As per my understandning ipsec in linux kernel uses linux kernel crypto not OCF framework? Is there any work done for this? Regards Manish |
|
From: David M. <Dav...@se...> - 2008-07-04 14:08:31
|
Jivin Andreas Steinel lays it down ... > Hi everybody, > > I tried todays version 20080704 and doesn't get it work. Here a detailed list: > * Debian Etch (4.0) running on Soekris 5501 with AMD Geode > * Kernel running 2.6.25.10-soekris #6 Fri Jul 4 15:53:42 CEST 2008 > i586 GNU/Linux > * Modules compiled and running: > Module Size Used by > cryptodev 13572 0 > ocf 27764 1 cryptodev > geode_aes 6628 0 It is proabbly because you have no OCF crypto drivers installed. You need to load cryptosoft to take advantage of the in kernel geode driver. If it doesn't work let us know, Cheers, Davidm > * openssl is compiled and cryptodev can be choosen as engine, but no > change to dynamic > * cryptotest doesn't work: > # ./cryptotest -v -a aes > crid = 3000000 > cipher aes keylen 16 > CIOCGSESSION: Invalid argument > > Any ideas? > > Best > Andreas > > ------------------------------------------------------------------------- > Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! > Studies have shown that voting for your favorite open source project, > along with a healthy diet, reduces your potential for chronic lameness > and boredom. Vote Now at http://www.sourceforge.net/community/cca08 > _______________________________________________ > Ocf-linux-users mailing list > Ocf...@li... > https://lists.sourceforge.net/lists/listinfo/ocf-linux-users > -- David McCullough, dav...@se..., Ph:+61 734352815 Secure Computing - SnapGear http://www.uCdot.org http://www.snapgear.com |
|
From: Andreas S. <a.s...@go...> - 2008-07-04 12:53:40
|
Hi everybody, I tried todays version 20080704 and doesn't get it work. Here a detailed list: * Debian Etch (4.0) running on Soekris 5501 with AMD Geode * Kernel running 2.6.25.10-soekris #6 Fri Jul 4 15:53:42 CEST 2008 i586 GNU/Linux * Modules compiled and running: Module Size Used by cryptodev 13572 0 ocf 27764 1 cryptodev geode_aes 6628 0 * openssl is compiled and cryptodev can be choosen as engine, but no change to dynamic * cryptotest doesn't work: # ./cryptotest -v -a aes crid = 3000000 cipher aes keylen 16 CIOCGSESSION: Invalid argument Any ideas? Best Andreas |
|
From: David M. <Dav...@se...> - 2008-07-04 05:49:54
|
Hi all,
A new release of the ocf-linux package is up (20080704):
http://ocf-linux.sourceforge.net/
This is primarily to sync up with openswan 2.6 and should be considered
somewhat alpha level code for now. Also figured I should get a full
snapshot out there ;-)
* lockup bug fixed
* other cleanups
* openswan-2.6.15dr2 patch
* linux-2.6.25 support
See the Changelog for more. Tested under 2.6.25 on Xscale so far, so
anything else may be fun ;-)
Cheers,
Davidm
--
David McCullough, dav...@se..., Ph:+61 734352815
Secure Computing - SnapGear http://www.uCdot.org http://www.snapgear.com
|
|
From: David M. <Dav...@se...> - 2008-07-01 23:48:38
|
Jivin John Gumb lays it down ... > Hi Folks > > Is there any reason why the hifn 7751 driver doesn't support the CIOCKEY > operation to facilitate in diffie-hellman calculations (a^b mod m)? Unless you have a particularly slow CPU the gains here are minimal. >From experience most CPU's can crunch the numbers just as fast, so the benefit is in the CPU offload. So you need to have other things to do while waiting for the result from the crypto chip in order to see any gain. Also, the MOD_EXP acceleration is a very small part of the entire key exchange process, so even if you reduce it to zero time and zero overhead, it still isn't a huge gain overall :-( > It seems there are some #defines for HIFN_VULCANDEV which appear to be > related to using the private/public key stuff which the card supports > from 'user mode' but I can't seem to find out much about this. The HIFN_VULCANDEV stuff is not complete and not used in the current source. > Seems like the right way to expose this functionality is via CIOCKEY I think the xelerance guys did some work here. The current driver doesn't support the newer hifn chips IIRC (ie., the ones that need the hifn dev kit to build). There may be a driver out there but I haven't put in the effort to find it and pull the support back in to OCF. You should be able to find something by following: http://www.xelerance.com/pr/20070205/ It would be nice to get the rest of this support back into OCF at some point if there is anything still missing. Both the safenet and ixp drivers do CRK_MOD_EXP on the appropriate HW if you need a reference, Cheers, Davidm -- David McCullough, dav...@se..., Ph:+61 734352815 Secure Computing - SnapGear http://www.uCdot.org http://www.snapgear.com |
|
From: John G. <joh...@ta...> - 2008-07-01 23:25:22
|
Hi Folks Is there any reason why the hifn 7751 driver doesn't support the CIOCKEY operation to facilitate in diffie-hellman calculations (a^b mod m)? It seems there are some #defines for HIFN_VULCANDEV which appear to be related to using the private/public key stuff which the card supports from 'user mode' but I can't seem to find out much about this. Seems like the right way to expose this functionality is via CIOCKEY Any insight appreciated Cheers John |
|
From: David M. <Dav...@se...> - 2008-06-22 23:55:19
|
Jivin John Gumb lays it down ... > Folks > > Should config OCF_RANDOMHARVEST be a bool rather than a tristate? Bool AFAICT, I don't know how it became something else :-) Cheers, Davidm -- David McCullough, dav...@se..., Ph:+61 734352815 Secure Computing - SnapGear http://www.uCdot.org http://www.snapgear.com |
|
From: John G. <joh...@ta...> - 2008-06-22 10:14:29
|
Folks Should config OCF_RANDOMHARVEST be a bool rather than a tristate? Apologies if this has already been raised. Johm |
|
From: John G. <joh...@ta...> - 2008-06-21 00:09:24
|
Folks Between ocf-linux-20060331 and ocf-linux-20071215 something got into the hifn driver which causes a kernel panic under load calculating digests. By pretty much brute force I think I've tracked down what's causing it. The patch kinda speaks for itself but its all related to moving towards a common crypto_copyback function. Reinstating crp->crp_mac rather than using crp->crp_buf and the complexity that entails in crypto_copyback/cuio_copyback seems to fix it. I don't pretend to understand this but it does seem to work for us. As I say, the crash only happens under heavy load and if I have ENABLE_DIGESTS on in the openssl eng_cryptodev.c Just thought I'd let you know or might help someone. Patch and panic signature attached. cheers John Gumb |
|
From: Xianghua X. <x....@fr...> - 2008-06-03 21:37:05
|
I tried them on 2.6.24 using PSK for subnetA-GW1-GW2-subnetB. run "ipsec eroute" showed a tunnel is up betwwen GW1-GW2. However when I send packets from subnetA to subnetB, it seems the vpn channel is not involved, i.e. I got the same throughput with/without ipsec. I disabled OCF totally for the debugging, also when "ifconfig ipsec0" I saw zero packets are Tx/Rx-ed, though eth1/eth0 has lots of packets Tx/Rx-ed, seems like ipsec0 is bypassed totally. Any suggestions? Thanks, Xianghua David McCullough wrote: > > Jivin xianghua xiao lays it down ... > ... > > Yes I would like to try your alpha tarball right away. I managed to get > > KLIPS compiled under 2.6.24 but it crashes sometimes, plus pluto > > complained "no hardware accelerator was found". > > Ok, here is everything I think you need and is easiest to generate. > It's a openswan-2.4.12 patch and a diff against the old 2007 release of > OCF. Ince you have openssl working I don't think you need a new version > of that patch. > > This is not as nicely packaged as a release, but I think you will be > able to work out what you need, if not hassle me :-) > > > Hope someday NETKEY can invoke OCF directly, that will make life easier. > > Or some writes crypto drivers for linux for the HW you are using :-) > > > There are quite a lot legacy network code in OpenSwan (partially due to > > its back-compatibility support) and it's becoming harder to keep KLIPS > > in sync with new kernel releases. > > It's not too bad actually, we update kernels regularly and while > openswan is often an issue, it's not always the worst offender :-) > > Cheers, > Davidm > > -- > David McCullough, dav...@se..., Ph:+61 > 734352815 > Secure Computing - SnapGear http://www.uCdot.org > http://www.snapgear.com > |
|
From: David M. <Dav...@se...> - 2008-06-02 23:19:49
|
Jivin "Adam Cécile (Le_Vert)" lays it down ... > Daniel Mueller a écrit : > > On Mon, 02 Jun 2008 17:25:23 +0200 Adam Cécile wrote: > > > > I do not own a AMD Geode but.. > > > > > >> Loaded kernel modules: > >> gandalf@alix:~$ lsmod | grep -e cry -e oc > >> cryptodev 13988 3 > >> crypto_null 2624 0 > >> cryptosoft 12136 0 > >> ocf 28984 2 cryptodev,cryptosoft > >> > > > > .. you need to load the geode-aes module as well. You can find it in > > your kernel configuration. > > > > Cryptographic API ---> > > [*] Hardware crypto devices ---> > > <M> Support for the Geode LX AES engine > > > > Try to load the modules in the following order: > > geode-aes.ko > > ocf.ko > > cryptosoft.ko > > cryptodev.ko > > > > bye, > > danm > > > > > gandalf@alix:~$ cat /etc/modules > # /etc/modules: kernel modules to load at boot time. > # > # This file contains the names of kernel modules that should be loaded > # at boot time, one per line. Lines beginning with "#" are ignored. > > # Geode WatchDog > geodewdt > > # Geode LX AES hardware crypto > geode-aes > geode-rng > ocf > cryptosoft > cryptodev > > # Alix LEDs driver > leds-alix > > # Sensors > lm90 > > It's already loaded. Any other idea ? ;) Did you check that with a "lsmod" to be sure ? Thanks, Davidm -- David McCullough, dav...@se..., Ph:+61 734352815 Secure Computing - SnapGear http://www.uCdot.org http://www.snapgear.com |
|
From: David M. <Dav...@se...> - 2008-06-02 23:18:52
|
Jivin "Adam Cécile (Le_Vert)" lays it down ... > Hello, > > Could you please help me to figure out what's wrong with my OCF setup ? > Here are some useful commands run on the Geode: > > Loaded kernel modules: > gandalf@alix:~$ lsmod | grep -e cry -e oc > cryptodev 13988 3 > crypto_null 2624 0 > cryptosoft 12136 0 > ocf 28984 2 cryptodev,cryptosoft > > Device node: > gandalf@alix:~$ ls -lah /dev/crypto > crw-rw-rw- 1 root root 10, 70 jun 2 17:11 /dev/crypto > > OpenSSL engines: > gandalf@alix:~$ openssl engine > (cryptodev) BSD cryptodev engine > (padlock) VIA PadLock (no-RNG, no-ACE) > (dynamic) Dynamic engine loading support > > Speed (without cryptodev): > gandalf@alix:~$ openssl speed -evp aes128 -elapsed > 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 aes-128-cbc for 3s on 16 size blocks: 270767 aes-128-cbc's in 3.00s > Doing aes-128-cbc for 3s on 64 size blocks: 183585 aes-128-cbc's in 3.00s > Doing aes-128-cbc for 3s on 256 size blocks: 84286 aes-128-cbc's in 3.00s > Doing aes-128-cbc for 3s on 1024 size blocks: 25353 aes-128-cbc's in 3.00s > Doing aes-128-cbc for 3s on 2048 size blocks: 13786 aes-128-cbc's in 3.00s > OpenSSL 0.9.8g 19 Oct 2007 > built on: Mon Jun 2 14:52:51 UTC 2008 > options:bn(64,32) md2(int) rc4(idx,int) des(ptr,risc1,16,long) > aes(partial) blowfish(idx) > compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT > -DDSO_DLFCN -DHAVE_DLFCN_H -DHAVE_CRYPTODEV -DL_ENDIAN -DTERMIO -O3 > -march=i586 -Wa,--noexecstack -g -Wall -DOPENSSL_BN_ASM_PART_WORDS > -DOPENSSL_IA32_SSE2 -DSHA1_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM > available timing options: TIMES TIMEB HZ=100 [sysconf value] > timing function used: ftime > The 'numbers' are in 1000s of bytes per second processed. > type 16 bytes 64 bytes 256 bytes 1024 bytes 2048 > bytes > aes-128-cbc 1444.09k 3916.48k 7192.41k 8653.82k > 9408.11k > > Speed (with cryptodev): > gandalf@alix:~$ openssl speed -evp aes128 -elapsed -engine cryptodev > 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 aes-128-cbc for 3s on 16 size blocks: 270840 aes-128-cbc's in 3.00s > Doing aes-128-cbc for 3s on 64 size blocks: 188479 aes-128-cbc's in 3.00s > Doing aes-128-cbc for 3s on 256 size blocks: 84691 aes-128-cbc's in 3.00s > Doing aes-128-cbc for 3s on 1024 size blocks: 26627 aes-128-cbc's in 3.00s > Doing aes-128-cbc for 3s on 2048 size blocks: 13889 aes-128-cbc's in 3.00s > OpenSSL 0.9.8g 19 Oct 2007 > built on: Mon Jun 2 14:52:51 UTC 2008 > options:bn(64,32) md2(int) rc4(idx,int) des(ptr,risc1,16,long) > aes(partial) blowfish(idx) > compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT > -DDSO_DLFCN -DHAVE_DLFCN_H -DHAVE_CRYPTODEV -DL_ENDIAN -DTERMIO -O3 > -march=i586 -Wa,--noexecstack -g -Wall -DOPENSSL_BN_ASM_PART_WORDS > -DOPENSSL_IA32_SSE2 -DSHA1_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM > available timing options: TIMES TIMEB HZ=100 [sysconf value] > timing function used: ftime > The 'numbers' are in 1000s of bytes per second processed. > type 16 bytes 64 bytes 256 bytes 1024 bytes 2048 > bytes > aes-128-cbc 1444.48k 4020.89k 7226.97k 9088.68k > 9481.56k So obviously openssl is not using OCF :-) If it was it would be slower for smaller operations and faster for large operations. No sure if you have told me before, but, have you patched openssl ? Which version of OCF did you use ? Make sure you are using the latest openssl patches. The current openssl patches will use cryptodev by default if it supports the alg you are using. I don't have a geode handy, but I just tried it on a VIA board (padlock aes) and it is working ok there, see below for an idea on output. Cheers, Davidm # rmmod cryptosoft # # openssl speed -evp aes128 -elapsed 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 aes-128-cbc for 3s on 16 size blocks: 2400255 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 64 size blocks: 678551 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 256 size blocks: 175440 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 1024 size blocks: 44201 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 2048 size blocks: 22141 aes-128-cbc's in 3.00s OpenSSL 0.9.8g 19 Oct 2007 built on: Mon May 19 14:42:05 EST 2008 options:bn(64,32) rc4(ptr,int) des(ptr,risc1,16,long) aes(partial) blowfish(idx) compiler: ucfront-gcc i386-linux-20070808-gcc -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DHAVE_CRYPTODEV -DOPENSSL_NO_ERR -DOPENSSL_NO_HW -O1 -g -fomit-frame-pointer -pipe -fno-common -fno-builtin -Wall -DCONFIG_SNAPGEAR -DEMBED available timing options: TIMES TIMEB HZ=100 [sysconf value] timing function used: ftime The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 2048 bytes aes-128-cbc 12801.36k 14461.29k 14955.92k 15067.19k 15094.80k # # # modprobe cryptosoft # # # openssl speed -evp aes128 -elapsed 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 aes-128-cbc for 3s on 16 size blocks: 1244481 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 64 size blocks: 1202468 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 256 size blocks: 1063384 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 1024 size blocks: 740477 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 2048 size blocks: 524824 aes-128-cbc's in 3.00s OpenSSL 0.9.8g 19 Oct 2007 built on: Mon May 19 14:42:05 EST 2008 options:bn(64,32) rc4(ptr,int) des(ptr,risc1,16,long) aes(partial) blowfish(idx) compiler: ucfront-gcc i386-linux-20070808-gcc -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DHAVE_CRYPTODEV -DOPENSSL_NO_ERR -DOPENSSL_NO_HW -O1 -g -fomit-frame-pointer -pipe -fno-common -fno-builtin -Wall -DCONFIG_SNAPGEAR -DEMBED available timing options: TIMES TIMEB HZ=100 [sysconf value] timing function used: ftime The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 2048 bytes aes-128-cbc 6635.02k 25627.02k 90651.45k 252496.99k 357921.93k # -- David McCullough, dav...@se..., Ph:+61 734352815 Secure Computing - SnapGear http://www.uCdot.org http://www.snapgear.com |
|
From: Daniel M. <da...@da...> - 2008-06-02 21:57:25
|
On Mon, 02 Jun 2008 21:45:15 +0200 Adam Cécile wrote: > It's already loaded. Any other idea ? ;) In this case no, sorry. bye, danm -- Daniel Mueller http://www.danm.de Berlin, Germany OpenPGP: F9F982C1 |
|
From: Adam C. (Le_Vert) <ga...@le...> - 2008-06-02 19:45:22
|
Daniel Mueller a écrit : > On Mon, 02 Jun 2008 17:25:23 +0200 Adam Cécile wrote: > > I do not own a AMD Geode but.. > > >> Loaded kernel modules: >> gandalf@alix:~$ lsmod | grep -e cry -e oc >> cryptodev 13988 3 >> crypto_null 2624 0 >> cryptosoft 12136 0 >> ocf 28984 2 cryptodev,cryptosoft >> > > .. you need to load the geode-aes module as well. You can find it in > your kernel configuration. > > Cryptographic API ---> > [*] Hardware crypto devices ---> > <M> Support for the Geode LX AES engine > > Try to load the modules in the following order: > geode-aes.ko > ocf.ko > cryptosoft.ko > cryptodev.ko > > bye, > danm > > gandalf@alix:~$ cat /etc/modules # /etc/modules: kernel modules to load at boot time. # # This file contains the names of kernel modules that should be loaded # at boot time, one per line. Lines beginning with "#" are ignored. # Geode WatchDog geodewdt # Geode LX AES hardware crypto geode-aes geode-rng ocf cryptosoft cryptodev # Alix LEDs driver leds-alix # Sensors lm90 It's already loaded. Any other idea ? ;) |
|
From: Daniel M. <da...@da...> - 2008-06-02 17:05:40
|
On Mon, 02 Jun 2008 17:25:23 +0200 Adam Cécile wrote: I do not own a AMD Geode but.. > Loaded kernel modules: > gandalf@alix:~$ lsmod | grep -e cry -e oc > cryptodev 13988 3 > crypto_null 2624 0 > cryptosoft 12136 0 > ocf 28984 2 cryptodev,cryptosoft .. you need to load the geode-aes module as well. You can find it in your kernel configuration. Cryptographic API ---> [*] Hardware crypto devices ---> <M> Support for the Geode LX AES engine Try to load the modules in the following order: geode-aes.ko ocf.ko cryptosoft.ko cryptodev.ko bye, danm -- Daniel Mueller http://www.danm.de Berlin, Germany OpenPGP: F9F982C1 |
|
From: Adam C. (Le_Vert) <ga...@le...> - 2008-06-02 15:25:29
|
Hello, Could you please help me to figure out what's wrong with my OCF setup ? Here are some useful commands run on the Geode: Loaded kernel modules: gandalf@alix:~$ lsmod | grep -e cry -e oc cryptodev 13988 3 crypto_null 2624 0 cryptosoft 12136 0 ocf 28984 2 cryptodev,cryptosoft Device node: gandalf@alix:~$ ls -lah /dev/crypto crw-rw-rw- 1 root root 10, 70 jun 2 17:11 /dev/crypto OpenSSL engines: gandalf@alix:~$ openssl engine (cryptodev) BSD cryptodev engine (padlock) VIA PadLock (no-RNG, no-ACE) (dynamic) Dynamic engine loading support Speed (without cryptodev): gandalf@alix:~$ openssl speed -evp aes128 -elapsed 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 aes-128-cbc for 3s on 16 size blocks: 270767 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 64 size blocks: 183585 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 256 size blocks: 84286 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 1024 size blocks: 25353 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 2048 size blocks: 13786 aes-128-cbc's in 3.00s OpenSSL 0.9.8g 19 Oct 2007 built on: Mon Jun 2 14:52:51 UTC 2008 options:bn(64,32) md2(int) rc4(idx,int) des(ptr,risc1,16,long) aes(partial) blowfish(idx) compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DHAVE_CRYPTODEV -DL_ENDIAN -DTERMIO -O3 -march=i586 -Wa,--noexecstack -g -Wall -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DSHA1_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM available timing options: TIMES TIMEB HZ=100 [sysconf value] timing function used: ftime The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 2048 bytes aes-128-cbc 1444.09k 3916.48k 7192.41k 8653.82k 9408.11k Speed (with cryptodev): gandalf@alix:~$ openssl speed -evp aes128 -elapsed -engine cryptodev 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 aes-128-cbc for 3s on 16 size blocks: 270840 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 64 size blocks: 188479 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 256 size blocks: 84691 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 1024 size blocks: 26627 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 2048 size blocks: 13889 aes-128-cbc's in 3.00s OpenSSL 0.9.8g 19 Oct 2007 built on: Mon Jun 2 14:52:51 UTC 2008 options:bn(64,32) md2(int) rc4(idx,int) des(ptr,risc1,16,long) aes(partial) blowfish(idx) compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DHAVE_CRYPTODEV -DL_ENDIAN -DTERMIO -O3 -march=i586 -Wa,--noexecstack -g -Wall -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DSHA1_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM available timing options: TIMES TIMEB HZ=100 [sysconf value] timing function used: ftime The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 2048 bytes aes-128-cbc 1444.48k 4020.89k 7226.97k 9088.68k 9481.56k Thanks in advance for your help. Best regards, Adam. |
|
From: Killerx G <kil...@ya...> - 2008-06-02 04:37:47
|
>What speed is your IXP platform ?
I am using IXP425 running at 425MHz
> We get somewhere between 35-40Mbps out of an accelerated IXP using openswan.
That's great.
> It sounds like you do not have OCF enabled for openswan at all ?
> 3Mbps is very slow,
When I enable debug (i.e. insmod ixp4xx ixp_deug=1), after insmod ipsec.o,
I got following log:
klips_info:ipsec_init: KLIPS startup, Openswan KLIPS IPsec stack version: 2.4.11
klips_info:ipsec_alg_init: KLIPS alg v=0.8.1-0 (EALG_MAX=255, AALG_MAX=251)
klips_info:ipsec_alg_init: calling ipsec_alg_static_init()
ipsec_aes_init(alg_type=15 alg_id=12 name=aes): ret=0
klips_debug: experimental ipsec_alg_AES_MAC not registered [Ok] (auth_id=0)
ipsec_3des_init(alg_type=15 alg_id=3 name=3des): ret=0
ixp_newsession():alg 6
ixp_freesession()
ixp_newsession():alg 7
ixp_freesession()
ixp_newsession():alg 11
ixp_freesession()
ixp_newsession():alg 2
ixp_freesession()
ixp_newsession():alg 1
ixp_freesession()
ixp_newsession():alg 6
ixp_freesession()
ixp_newsession():alg 7
ixp_freesession()
During throughput test, I got many logs like:
ixp_q_process(c2a90080)
ixp_process()
ixp_q_process(c2a901c0)
ixp_perform_cb(-1023479488, c2a900a0, 00000000, 0x0)
ixp_perform_cb(-1023479488, c2a901e0, 00000000, 0x0)
....
The max. throughput I can get is 1.5Mbit/sec (without ipsec, it is > 90Mbit/sec).
Anything I am missing?
Kil
|
|
From: David M. <Dav...@se...> - 2008-06-02 00:01:09
|
Jivin Killerx G lays it down ... > Hi, > > I managed to patch linux 2.4.32, openssl 0.98g and openswan 2.4.11 to work with OCF in IXP425 platform (using ocf-linux-20071215 release). > > The performance with ixp4xx h/w crypto driver is about 15% lower than the benchmark in > http://ocf-linux.sourceforge.net/benchmarks.html I think there have been a few required slow downs since those were done. > When tested with openswan 2.4.11, I can only get at most 1.2Mbit/sec with esp-3des-md5 and esp-aes-md5 (using ixp4xx driver). Without ocf, the throughput is around 500Kbit/s. > > I expected to have at least 6x performance gain (i.e. 3Mbit/s) with IXP425 hw crypto (since I can get that figure with openssl). Does anyone tried ocf with IXP425/openswan ? What is the throughput you can get? What speed is your IXP platform ? We get somewhere between 35-40Mbps out of an accelerated IXP using openswan. It sounds like you do not have OCF enabled for openswan at all ? 3Mbps is very slow, Cheers, Davidm -- David McCullough, dav...@se..., Ph:+61 734352815 Secure Computing - SnapGear http://www.uCdot.org http://www.snapgear.com |
4 messages has been excluded from this view by a project administrator.
