ocf-linux-users Mailing List for Open Cryptographic Framework for Linux (Page 3)
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: Stefan K. <ste...@gm...> - 2012-12-03 17:18:35
|
Am 03.12.2012 16:45, schrieb Stefan Kuhne: Hallo, > CC drivers/char/random.o > drivers/char/random.c: In Funktion »random_input_words«: > drivers/char/random.c:824:2: Fehler: Zu wenige Argumente für Funktion > »mix_pool_bytes« > drivers/char/random.c:556:13: Anmerkung: hier deklariert > make[2]: *** [drivers/char/random.o] Fehler 1 > make[1]: *** [drivers/char] Fehler 2 > make: *** [drivers] Fehler 2 > make: *** Warte auf noch nicht beendete Prozesse... > FAILED, aborting build ... > it compiles, when I change: + mix_pool_bytes(&input_pool, buf, wordcount*4); into: + mix_pool_bytes(&input_pool, buf, wordcount*4, NULL); Regards, Stefan Kuhne |
|
From: Stefan K. <ste...@gm...> - 2012-12-03 15:46:39
|
Am 03.12.2012 01:09, schrieb David McCullough:
> Jivin Stefan Kuhne lays it down ...
Hello,
>> I try to get OCF with openssl and openvpn running.
>> I've read in README that the patch is created with "make patch".
>> But with this Patch the kernel doesn't build.
>> Where looks the Makefile for the kernel headers?
>
> What kernel version are you using ?
>
it is 3.6.8.
> What are the errors when you build ?
>
The 1st run hangs on
LD [M] sound/pci/snd-via82xx.o
LD [M] sound/pci/snd-via82xx-modem.o
LD [M] sound/pci/ymfpci/snd-ymfpci.o
FAILED, aborting build ...
and a next make stopps at:
CC drivers/char/random.o
drivers/char/random.c: In Funktion »random_input_words«:
drivers/char/random.c:824:2: Fehler: Zu wenige Argumente für Funktion
»mix_pool_bytes«
drivers/char/random.c:556:13: Anmerkung: hier deklariert
make[2]: *** [drivers/char/random.o] Fehler 1
make[1]: *** [drivers/char] Fehler 2
make: *** [drivers] Fehler 2
make: *** Warte auf noch nicht beendete Prozesse...
FAILED, aborting build ...
Regards,
Stefan Kuhne
|
|
From: David M. <dav...@mc...> - 2012-12-03 00:09:25
|
Jivin Stefan Kuhne lays it down ... > Hello, > > I try to get OCF with openssl and openvpn running. > I've read in README that the patch is created with "make patch". > But with this Patch the kernel doesn't build. > Where looks the Makefile for the kernel headers? What kernel version are you using ? What are the errors when you build ? Cheers, Davidm -- David McCullough, dav...@mc..., Ph:+61 734352815 McAfee - SnapGear http://www.mcafee.com http://www.uCdot.org |
|
From: Stefan K. <ste...@gm...> - 2012-12-02 22:02:15
|
Hello, I try to get OCF with openssl and openvpn running. I've read in README that the patch is created with "make patch". But with this Patch the kernel doesn't build. Where looks the Makefile for the kernel headers? Regards, Stefan Kuhne |
|
From: Nikolaos T. <nts...@ya...> - 2012-11-29 13:01:57
|
Hi all,
I have the same issues concerning --with-cryptodev-digests flag, and the reply to the belowmentioned questions will turn out to be very useful for me, too.
Kind Regards/Με ευχές
Nikolaos Tsakalakis
>________________________________
> Απο: nikos karag <kar...@wi...>
>Προς: ocf...@li...
>Στάλθηκε: 5:59 μ.μ. Δευτέρα, 5 Νοεμβρίου 2012
>Θεμα: [Ocf-linux-users] How stable is Openssl Configuration Option --with-cryptodev-digests?
>
>
>
>Hello!
>
>
>I have some questions concerning the openssl configuration option --with-cryptodev-digests.
>
>
>1. Does the option --with-cryptodev-digests is necessary only for MD5/SHA hardware acceleration?
>
>2. In addition by applying the openssl-0.9.8r.patch (in order to use the OCF from openssl) i had some compilation problems with the option --with-cryptodev-digests.
>The reasons have to do with some inactive pieces of code (#if 0) inside of some files of openssl.
>
>
>For example in file
>openssl-0.9.8r\crypto\engine\eng_cryptodev.c at line 146
>#if 0
>static struct {
>intid;
>intnid;
>} digests[] = {
>{ CRYPTO_SHA1_HMAC,NID_hmacWithSHA1,},
>{ CRYPTO_RIPEMD160_HMAC,NID_ripemd160,},
>{ CRYPTO_MD5_KPDK,NID_undef,},
>{ CRYPTO_SHA1_KPDK,NID_undef,},
>{ CRYPTO_MD5,NID_md5,},
>{ CRYPTO_SHA1,NID_undef,},
>{ 0,NID_undef,},
>};
>#endif
>
>
>there is a piece of code inside at #if 0
>In order to compile with --with-cryptodev-digests i replace the #if 0 with #ifdef USE_CRYPTODEV_DIGESTS
>Is this the suitable procedure for compilation with --with-cryptodev-digests? Why openssl has these pieces of code inactive?
>
>
>3. Also with --with-cryptodev-digests there are some reported problems e.g.
>http://sourceforge.net/mailarchive/forum.php?forum_name=ocf-linux-users&max_rows=25&style=nested&viewmonth=200805
>
>
>Some problems i encountered also by myself
>By run the comand
>
>
># openssl x509 -in usercert.pem -signkey userkey.pem -out cert.crt
>i take the error:
>
>
>Getting Private key
>5480:error:0606B06E:digital envelope routines:EVP_SignFinal:wrong public key type:p_sign.c:99:
>5480:error:0D0C3006:asn1 encoding routines:ASN1_item_sign:EVP lib:a_sign.c:281:
>
>
>By removing the option --with-cryptodev-digests this error was disappeared.
>
>
>What is the directives concerning the --with-cryptodev-digests?
>Is it stable? How we can overcome such problems (EVP_SignFinal:wrong public key type)?
>
>
>Thanks a lot!
>------------------------------------------------------------------------------
>LogMeIn Central: Instant, anywhere, Remote PC access and management.
>Stay in control, update software, and manage PCs from one command center
>Diagnose problems and improve visibility into emerging IT issues
>Automate, monitor and manage. Do more in less time with Central
>http://p.sf.net/sfu/logmein12331_d2d
>_______________________________________________
>Ocf-linux-users mailing list
>Ocf...@li...
>https://lists.sourceforge.net/lists/listinfo/ocf-linux-users
>
>
> |
|
From: anand r. <one...@ya...> - 2012-11-28 14:19:33
|
Hi David, >Are you running any patches to ocf-20120127 under OpenWRT ? No. I am not using any patches for ocf-20120127. Regards, Anand ----- Original Message ----- From: David McCullough <dav...@mc...> To: anand rao <one...@ya...> Cc: "ocf...@li..." <ocf...@li...> Sent: Wednesday, November 28, 2012 6:35 PM Subject: Re: [Ocf-linux-users] Crash observed when multiple SSL sessions are started Jivin anand rao lays it down ... > Hi, > > ???? I am encountering a crash in OCF, when I start a multiple SSL sessions. > Please find the attached crash log with this mail. I don't see anything here or in my current tree that would help so give me a few days and I'll see if I can reproduce it. Are you running any patches to ocf-20120127 under OpenWRT ? Cheers, Davidm > > My environment: > Linux kernel version 3.2.26, > OpenSSL version 1.0.0g > OCF linux 20120127 release. > > My setup: > I am running?? two servers on a PC using below commands > openssl s_server -accept 443 -cert evm1gwcert.pem -key evm1gwkey.pem -ssl3 -WWW > openssl s_server -accept 446 -cert evm4gwcert.pem -key evm4gwkey.pem -ssl3 -WWW > > from my board I am starting a client using below command > openssl s_time -connect 192.168.1.100:443 -www /cam1.mp4 -new -time 7200 -ssl3 -cipher HIGH & > > The above session is working fine. > > But when I start a second session > > openssl s_time -connect 192.168.1.100:446 -www /cam4.mp4 -new -time 7200 -ssl3 -cipher HIGH & > > I am observing a crash in OCF, > > If I unload the cryptodev module I am not observing any issue. > > Please help. > > Thanks, > Anand Rao > root@OpenWrt:/elp# [ 1833.370000] Unable to handle kernel NULL pointer dereference at virtual address 00000010 > [ 1833.380000] pgd = deaa4000 > [ 1833.380000] [00000010] *pgd=1e86e831, *pte=00000000, *ppte=00000000 > [ 1833.390000] Internal error: Oops: 17 [#1] SMP > [ 1833.390000] Modules linked in: fci(O) csmencaps(O) legerity(O) legerity_api(P) tempo(P) wan(P) common(P) turnkey_decomp(P) decomp(O) cie(O) ath_pktlog(P) umac(O) ath_dev(P) ath_dfs(P) ath_rate_atheros(P) ath_hal(P) asf(P) adf(P) nf_conntrack_netlink ip6t_REJECT ip6t_LOG ip6t_rt ip6t_hbh ip6t_mh ip6t_ipv6header ip6t_frag ip6t_eui64 ip6t_ah ip6table_raw ip6_queue ip6table_mangle ip6table_filter ip6_tables nf_conntrack_ipv6 nf_defrag_ipv6 ebt_redirect ebt_mark ebt_vlan ebt_stp ebt_pkttype ebt_mark_m ebt_limit ebt_among ebt_802_3 ebtable_nat ebtable_filter ebtable_broute ebtables nfnetlink nf_nat_tftp nf_conntrack_tftp nf_nat_sip nf_conntrack_sip nf_nat_pptp nf_conntrack_pptp nf_nat_h323 nf_conntrack_h323 nf_nat_proto_gre nf_conntrack_proto_gre nf_nat_amanda nf_conntrack_amanda nf_nat_irc nf_conntrack_irc nf_nat_ftp nf_conntrack_ftp xt_iprange xt_HL xt_hl ipt_ECN xt_CLASSIFY xt_time xt_tcpmss xt_statistic xt_mark xt_length ipt_ecn xt_DSCP xt_dscp xt_string xt_layer7 xt_quota xt_pkttype xt_physdev xt_owner ipt > _REDIRECT ipt_NETMAP ipt_MASQUERADE iptable_nat nf_nat xt_recent xt_helper xt_connmark xt_connbytes xt_conntrack xt_NOTRACK iptable_raw xt_state nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack pppoe pppox ipt_REJECT xt_TCPMSS ipt_LOG xt_comment xt_multiport xt_mac xt_limit iptable_mangle iptable_filter ip_tables xt_tcpudp x_tables ppp_async ppp_generic slhc vfat fat nls_iso8859_15 nls_iso8859_1 nls_cp437 ts_fsm ts_bm ts_kmp crc_ccitt cryptosoft cryptodev(P) ocf(P) pfe(O) [last unloaded: m86xxx_elp] > [ 1833.390000] CPU: 1 Tainted: P O (3.2.26 #2) > [ 1833.390000] PC is at doing_it_now+0x5c/0x1b0 [cryptosoft] > [ 1833.390000] LR is at swcr_process_req+0xdc0/0xe8c [cryptosoft] > [ 1833.390000] pc : [<bf06d0cc>] lr : [<bf06dfe0>] psr: 60000013 > [ 1833.390000] sp : ddf91bb0 ip : ddf91bd0 fp : ddf91bcc > [ 1833.390000] r10: bebc665c r9 : 00000000 r8 : bf062480 > [ 1833.390000] r7 : dead55e0 r6 : df1a6060 r5 : df1a6060 r4 : 00000000 > [ 1833.390000] r3 : 00000000 r2 : 0000000b r1 : ffffffe4 r0 : 00000000 > [ 1833.390000] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user > [ 1833.390000] Control: 10c53c7d Table: 1eaa404a DAC: 00000015 > [ 1833.390000] Process openssl (pid: 1916, stack limit = 0xddf90270) > [ 1833.390000] Stack: (0xddf91bb0 to 0xddf92000) > [ 1833.390000] 1ba0: c01581dc c015e40c 00000000 df01ccc0 > [ 1833.390000] 1bc0: ddf91c64 ddf91bd0 bf06dfe0 bf06d0a4 c015f010 c015819c de6e9880 c0373454 > [ 1833.390000] 1be0: deb0151c de6e9840 ddf91c04 ddf91bf8 c015db90 c015efec ddf91c24 ddf91c08 > [ 1833.390000] 1c00: c01581dc c015db5c ddf90000 deb01968 c04a8e78 c0373454 ddf91c54 ddf91c28 > [ 1833.390000] 1c20: c01585dc c015819c 00000000 dfb848e0 deb01968 ddf91d60 0000000a 0000000a > [ 1833.390000] 1c40: dead55e0 df1a6060 bf06fb5c bf062480 00000000 bebc665c ddf91c84 ddf91c68 > [ 1833.390000] 1c60: bf06e260 bf06d22c dead55e0 df25c400 00000000 00000000 ddf91cac ddf91c88 > [ 1833.390000] 1c80: bf05f648 bf06e0b8 ddf91eb0 00000000 dead55e0 dead55e0 df25c400 60000013 > [ 1833.390000] 1ca0: ddf91cd4 ddf91cb0 bf05ff80 bf05f55c bebc6708 bf069554 00000000 deb014c0 > [ 1833.390000] 1cc0: c01c6367 dead55e0 ddf91eec ddf91cd8 bf068410 bf05fe2c de9d2618 00000014 > [ 1833.390000] 1ce0: 00000394 ddfe6810 00000000 06000000 00000000 00000000 00000000 00000000 > [ 1833.390000] 1d00: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 > [ 1833.390000] 1d20: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 > [ 1833.390000] 1d40: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 > [ 1833.390000] 1d60: 0000000e 00000000 00000000 000000a0 ddcfd700 00000000 00000000 00000000 > [ 1833.390000] 1d80: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 > [ 1833.390000] 1da0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 > [ 1833.390000] 1dc0: 00000000 00000000 00000000 00000000 df595e60 00004020 ddf91e50 00000000 > [ 1833.390000] 1de0: ddf91e24 ddf91df0 c02c481c c02a7640 00000000 00000000 ddf91e04 c0923020 > [ 1833.390000] 1e00: 00000001 00000000 ddf91e04 ddf91e30 ddf91ea8 00000000 ddf91e9c ddf91e28 > [ 1833.390000] 1e20: 00000000 0000000e 00000000 00000000 00000014 00dad388 0000ab21 00000000 > [ 1833.390000] 1e40: 00000000 00000000 00000000 00000000 00000000 00000000 ddf91f28 00000001 > [ 1833.390000] 1e60: 00000000 00000000 00000000 ddf91ea8 ddf91eac 0000ab21 00000000 00000050 > [ 1833.390000] 1e80: 00daa950 00000000 bebc6708 00000000 ddf91f44 ddf91ea0 c00c699c c025ea20 > [ 1833.390000] 1ea0: 00000000 00000000 00000000 00000014 0000000a 06000000 ffffffff df040e60 > [ 1833.390000] 1ec0: 00000000 df13f628 df040320 bebc665c df040320 c00092a4 ddf90000 00000000 > [ 1833.390000] 1ee0: ddf91efc ddf91ef0 bf068d9c bf067318 ddf91f7c ddf91f00 c00d6f20 bf068d98 > [ 1833.390000] 1f00: ddf91f34 df040e68 c001f7fc 00000000 00000000 00000000 dfa010a0 df040e68 > [ 1833.390000] 1f20: 00004020 00000000 df595e80 00000001 ddf91f5c ddf91f40 c00d5678 c03622bc > [ 1833.390000] 1f40: df040320 00000002 df040320 00000001 ddf91f84 ddf91f60 c00d5a8c 0000000b > [ 1833.390000] 1f60: c01c6367 bebc665c c00092a4 ddf90000 ddf91fa4 ddf91f80 c00d6fd4 c00d6a30 > [ 1833.390000] 1f80: c00d5f04 00000000 00dad368 0000000b 00000000 00000036 00000000 ddf91fa8 > [ 1833.390000] 1fa0: c0009120 c00d6fa0 00dad368 0000000b 0000000b c01c6367 bebc665c 00daa950 > [ 1833.390000] 1fc0: 00dad368 0000000b 00000000 00000036 00d997c4 00000028 00d997b8 00000017 > [ 1833.390000] 1fe0: 401ec654 bebc6654 401543b8 402d1c3c 80000010 0000000b 00000000 00000000 > [ 1833.390000] Backtrace: > [ 1833.390000] [<bf06d098>] (doing_it_now+0x28/0x1b0 [cryptosoft]) from [<bf06dfe0>] (swcr_process_req+0xdc0/0xe8c [cryptosoft]) > [ 1833.390000] r5:df01ccc0 r4:00000000 > [ 1833.390000] [<bf06d220>] (swcr_process_req+0x0/0xe8c [cryptosoft]) from [<bf06e260>] (swcr_process+0x1b4/0x1f4 [cryptosoft]) > [ 1833.390000] [<bf06e0ac>] (swcr_process+0x0/0x1f4 [cryptosoft]) from [<bf05f648>] (crypto_done+0x2b4/0x2d4 [ocf]) > [ 1833.390000] r7:00000000 r6:00000000 r5:df25c400 r4:dead55e0 > [ 1833.390000] [<bf05f550>] (crypto_done+0x1bc/0x2d4 [ocf]) from [<bf05ff80>] (crypto_dispatch+0x160/0x294 [ocf]) > [ 1833.390000] r6:60000013 r5:df25c400 r4:dead55e0 > [ 1833.390000] [<bf05fe20>] (crypto_dispatch+0x0/0x294 [ocf]) from [<bf068410>] (cryptodevkey_cb+0x1158/0x1ad4 [cryptodev]) > [ 1833.390000] r8:dead55e0 r7:c01c6367 r6:deb014c0 r5:00000000 r4:bf069554 > [ 1833.390000] r3:bebc6708 > [ 1833.390000] [<bf06730c>] (cryptodevkey_cb+0x54/0x1ad4 [cryptodev]) from [<bf068d9c>] (cryptodev_unlocked_ioctl+0x10/0x14 [cryptodev]) > [ 1833.390000] [<bf068d8c>] (cryptodev_unlocked_ioctl+0x0/0x14 [cryptodev]) from [<c00d6f20>] (do_vfs_ioctl+0x4fc/0x570) > [ 1833.390000] [<c00d6a24>] (do_vfs_ioctl+0x0/0x570) from [<c00d6fd4>] (sys_ioctl+0x40/0x64) > [ 1833.390000] r9:ddf90000 r8:c00092a4 r6:bebc665c r5:c01c6367 r4:0000000b > [ 1833.390000] [<c00d6f94>] (sys_ioctl+0x0/0x64) from [<c0009120>] (ret_fast_syscall+0x0/0x30) > [ 1833.390000] r7:00000036 r6:00000000 r5:0000000b r4:00dad368 > [ 1833.390000] Code: e59f0150 e59f1150 eb4bca8b e5950004 (e5903010) > [ 1834.020000] ---[ end trace 8ebbc70bf64b8716 ]--- > 333 > [1]- Segmentation fault openssl s_time -connect 192.168.1.100:443 -www /cam1.mp4 -new -time 86400 -ssl3 -cipher HIGH > root@OpenWrt:/elp# > ------------------------------------------------------------------------------ > Monitor your physical, virtual and cloud infrastructure from a single > web console. Get in-depth insight into apps, servers, databases, vmware, > SAP, cloud infrastructure, etc. Download 30-day Free Trial. > Pricing starts from $795 for 25 servers or applications! > http://p.sf.net/sfu/zoho_dev2dev_nov > _______________________________________________ > Ocf-linux-users mailing list > Ocf...@li... > https://lists.sourceforge.net/lists/listinfo/ocf-linux-users -- David McCullough, dav...@mc..., Ph:+61 734352815 McAfee - SnapGear http://www.mcafee.com http://www.uCdot.org |
|
From: David M. <dav...@mc...> - 2012-11-28 13:05:55
|
Jivin anand rao lays it down ... > Hi, > > ???? I am encountering a crash in OCF, when I start a multiple SSL sessions. > Please find the attached crash log with this mail. I don't see anything here or in my current tree that would help so give me a few days and I'll see if I can reproduce it. Are you running any patches to ocf-20120127 under OpenWRT ? Cheers, Davidm > > My environment: > Linux kernel version 3.2.26, > OpenSSL version 1.0.0g > OCF linux 20120127 release. > > My setup: > I am running?? two servers on a PC using below commands > openssl s_server -accept 443 -cert evm1gwcert.pem -key evm1gwkey.pem -ssl3 -WWW > openssl s_server -accept 446 -cert evm4gwcert.pem -key evm4gwkey.pem -ssl3 -WWW > > from my board I am starting a client using below command > openssl s_time -connect 192.168.1.100:443 -www /cam1.mp4 -new -time 7200 -ssl3 -cipher HIGH & > > The above session is working fine. > > But when I start a second session > > openssl s_time -connect 192.168.1.100:446 -www /cam4.mp4 -new -time 7200 -ssl3 -cipher HIGH & > > I am observing a crash in OCF, > > If I unload the cryptodev module I am not observing any issue. > > Please help. > > Thanks, > Anand Rao > root@OpenWrt:/elp# [ 1833.370000] Unable to handle kernel NULL pointer dereference at virtual address 00000010 > [ 1833.380000] pgd = deaa4000 > [ 1833.380000] [00000010] *pgd=1e86e831, *pte=00000000, *ppte=00000000 > [ 1833.390000] Internal error: Oops: 17 [#1] SMP > [ 1833.390000] Modules linked in: fci(O) csmencaps(O) legerity(O) legerity_api(P) tempo(P) wan(P) common(P) turnkey_decomp(P) decomp(O) cie(O) ath_pktlog(P) umac(O) ath_dev(P) ath_dfs(P) ath_rate_atheros(P) ath_hal(P) asf(P) adf(P) nf_conntrack_netlink ip6t_REJECT ip6t_LOG ip6t_rt ip6t_hbh ip6t_mh ip6t_ipv6header ip6t_frag ip6t_eui64 ip6t_ah ip6table_raw ip6_queue ip6table_mangle ip6table_filter ip6_tables nf_conntrack_ipv6 nf_defrag_ipv6 ebt_redirect ebt_mark ebt_vlan ebt_stp ebt_pkttype ebt_mark_m ebt_limit ebt_among ebt_802_3 ebtable_nat ebtable_filter ebtable_broute ebtables nfnetlink nf_nat_tftp nf_conntrack_tftp nf_nat_sip nf_conntrack_sip nf_nat_pptp nf_conntrack_pptp nf_nat_h323 nf_conntrack_h323 nf_nat_proto_gre nf_conntrack_proto_gre nf_nat_amanda nf_conntrack_amanda nf_nat_irc nf_conntrack_irc nf_nat_ftp nf_conntrack_ftp xt_iprange xt_HL xt_hl ipt_ECN xt_CLASSIFY xt_time xt_tcpmss xt_statistic xt_mark xt_length ipt_ecn xt_DSCP xt_dscp xt_string xt_layer7 xt_quota xt_pkttype xt_physdev xt_owner ipt > _REDIRECT ipt_NETMAP ipt_MASQUERADE iptable_nat nf_nat xt_recent xt_helper xt_connmark xt_connbytes xt_conntrack xt_NOTRACK iptable_raw xt_state nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack pppoe pppox ipt_REJECT xt_TCPMSS ipt_LOG xt_comment xt_multiport xt_mac xt_limit iptable_mangle iptable_filter ip_tables xt_tcpudp x_tables ppp_async ppp_generic slhc vfat fat nls_iso8859_15 nls_iso8859_1 nls_cp437 ts_fsm ts_bm ts_kmp crc_ccitt cryptosoft cryptodev(P) ocf(P) pfe(O) [last unloaded: m86xxx_elp] > [ 1833.390000] CPU: 1 Tainted: P O (3.2.26 #2) > [ 1833.390000] PC is at doing_it_now+0x5c/0x1b0 [cryptosoft] > [ 1833.390000] LR is at swcr_process_req+0xdc0/0xe8c [cryptosoft] > [ 1833.390000] pc : [<bf06d0cc>] lr : [<bf06dfe0>] psr: 60000013 > [ 1833.390000] sp : ddf91bb0 ip : ddf91bd0 fp : ddf91bcc > [ 1833.390000] r10: bebc665c r9 : 00000000 r8 : bf062480 > [ 1833.390000] r7 : dead55e0 r6 : df1a6060 r5 : df1a6060 r4 : 00000000 > [ 1833.390000] r3 : 00000000 r2 : 0000000b r1 : ffffffe4 r0 : 00000000 > [ 1833.390000] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user > [ 1833.390000] Control: 10c53c7d Table: 1eaa404a DAC: 00000015 > [ 1833.390000] Process openssl (pid: 1916, stack limit = 0xddf90270) > [ 1833.390000] Stack: (0xddf91bb0 to 0xddf92000) > [ 1833.390000] 1ba0: c01581dc c015e40c 00000000 df01ccc0 > [ 1833.390000] 1bc0: ddf91c64 ddf91bd0 bf06dfe0 bf06d0a4 c015f010 c015819c de6e9880 c0373454 > [ 1833.390000] 1be0: deb0151c de6e9840 ddf91c04 ddf91bf8 c015db90 c015efec ddf91c24 ddf91c08 > [ 1833.390000] 1c00: c01581dc c015db5c ddf90000 deb01968 c04a8e78 c0373454 ddf91c54 ddf91c28 > [ 1833.390000] 1c20: c01585dc c015819c 00000000 dfb848e0 deb01968 ddf91d60 0000000a 0000000a > [ 1833.390000] 1c40: dead55e0 df1a6060 bf06fb5c bf062480 00000000 bebc665c ddf91c84 ddf91c68 > [ 1833.390000] 1c60: bf06e260 bf06d22c dead55e0 df25c400 00000000 00000000 ddf91cac ddf91c88 > [ 1833.390000] 1c80: bf05f648 bf06e0b8 ddf91eb0 00000000 dead55e0 dead55e0 df25c400 60000013 > [ 1833.390000] 1ca0: ddf91cd4 ddf91cb0 bf05ff80 bf05f55c bebc6708 bf069554 00000000 deb014c0 > [ 1833.390000] 1cc0: c01c6367 dead55e0 ddf91eec ddf91cd8 bf068410 bf05fe2c de9d2618 00000014 > [ 1833.390000] 1ce0: 00000394 ddfe6810 00000000 06000000 00000000 00000000 00000000 00000000 > [ 1833.390000] 1d00: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 > [ 1833.390000] 1d20: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 > [ 1833.390000] 1d40: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 > [ 1833.390000] 1d60: 0000000e 00000000 00000000 000000a0 ddcfd700 00000000 00000000 00000000 > [ 1833.390000] 1d80: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 > [ 1833.390000] 1da0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 > [ 1833.390000] 1dc0: 00000000 00000000 00000000 00000000 df595e60 00004020 ddf91e50 00000000 > [ 1833.390000] 1de0: ddf91e24 ddf91df0 c02c481c c02a7640 00000000 00000000 ddf91e04 c0923020 > [ 1833.390000] 1e00: 00000001 00000000 ddf91e04 ddf91e30 ddf91ea8 00000000 ddf91e9c ddf91e28 > [ 1833.390000] 1e20: 00000000 0000000e 00000000 00000000 00000014 00dad388 0000ab21 00000000 > [ 1833.390000] 1e40: 00000000 00000000 00000000 00000000 00000000 00000000 ddf91f28 00000001 > [ 1833.390000] 1e60: 00000000 00000000 00000000 ddf91ea8 ddf91eac 0000ab21 00000000 00000050 > [ 1833.390000] 1e80: 00daa950 00000000 bebc6708 00000000 ddf91f44 ddf91ea0 c00c699c c025ea20 > [ 1833.390000] 1ea0: 00000000 00000000 00000000 00000014 0000000a 06000000 ffffffff df040e60 > [ 1833.390000] 1ec0: 00000000 df13f628 df040320 bebc665c df040320 c00092a4 ddf90000 00000000 > [ 1833.390000] 1ee0: ddf91efc ddf91ef0 bf068d9c bf067318 ddf91f7c ddf91f00 c00d6f20 bf068d98 > [ 1833.390000] 1f00: ddf91f34 df040e68 c001f7fc 00000000 00000000 00000000 dfa010a0 df040e68 > [ 1833.390000] 1f20: 00004020 00000000 df595e80 00000001 ddf91f5c ddf91f40 c00d5678 c03622bc > [ 1833.390000] 1f40: df040320 00000002 df040320 00000001 ddf91f84 ddf91f60 c00d5a8c 0000000b > [ 1833.390000] 1f60: c01c6367 bebc665c c00092a4 ddf90000 ddf91fa4 ddf91f80 c00d6fd4 c00d6a30 > [ 1833.390000] 1f80: c00d5f04 00000000 00dad368 0000000b 00000000 00000036 00000000 ddf91fa8 > [ 1833.390000] 1fa0: c0009120 c00d6fa0 00dad368 0000000b 0000000b c01c6367 bebc665c 00daa950 > [ 1833.390000] 1fc0: 00dad368 0000000b 00000000 00000036 00d997c4 00000028 00d997b8 00000017 > [ 1833.390000] 1fe0: 401ec654 bebc6654 401543b8 402d1c3c 80000010 0000000b 00000000 00000000 > [ 1833.390000] Backtrace: > [ 1833.390000] [<bf06d098>] (doing_it_now+0x28/0x1b0 [cryptosoft]) from [<bf06dfe0>] (swcr_process_req+0xdc0/0xe8c [cryptosoft]) > [ 1833.390000] r5:df01ccc0 r4:00000000 > [ 1833.390000] [<bf06d220>] (swcr_process_req+0x0/0xe8c [cryptosoft]) from [<bf06e260>] (swcr_process+0x1b4/0x1f4 [cryptosoft]) > [ 1833.390000] [<bf06e0ac>] (swcr_process+0x0/0x1f4 [cryptosoft]) from [<bf05f648>] (crypto_done+0x2b4/0x2d4 [ocf]) > [ 1833.390000] r7:00000000 r6:00000000 r5:df25c400 r4:dead55e0 > [ 1833.390000] [<bf05f550>] (crypto_done+0x1bc/0x2d4 [ocf]) from [<bf05ff80>] (crypto_dispatch+0x160/0x294 [ocf]) > [ 1833.390000] r6:60000013 r5:df25c400 r4:dead55e0 > [ 1833.390000] [<bf05fe20>] (crypto_dispatch+0x0/0x294 [ocf]) from [<bf068410>] (cryptodevkey_cb+0x1158/0x1ad4 [cryptodev]) > [ 1833.390000] r8:dead55e0 r7:c01c6367 r6:deb014c0 r5:00000000 r4:bf069554 > [ 1833.390000] r3:bebc6708 > [ 1833.390000] [<bf06730c>] (cryptodevkey_cb+0x54/0x1ad4 [cryptodev]) from [<bf068d9c>] (cryptodev_unlocked_ioctl+0x10/0x14 [cryptodev]) > [ 1833.390000] [<bf068d8c>] (cryptodev_unlocked_ioctl+0x0/0x14 [cryptodev]) from [<c00d6f20>] (do_vfs_ioctl+0x4fc/0x570) > [ 1833.390000] [<c00d6a24>] (do_vfs_ioctl+0x0/0x570) from [<c00d6fd4>] (sys_ioctl+0x40/0x64) > [ 1833.390000] r9:ddf90000 r8:c00092a4 r6:bebc665c r5:c01c6367 r4:0000000b > [ 1833.390000] [<c00d6f94>] (sys_ioctl+0x0/0x64) from [<c0009120>] (ret_fast_syscall+0x0/0x30) > [ 1833.390000] r7:00000036 r6:00000000 r5:0000000b r4:00dad368 > [ 1833.390000] Code: e59f0150 e59f1150 eb4bca8b e5950004 (e5903010) > [ 1834.020000] ---[ end trace 8ebbc70bf64b8716 ]--- > 333 > [1]- Segmentation fault openssl s_time -connect 192.168.1.100:443 -www /cam1.mp4 -new -time 86400 -ssl3 -cipher HIGH > root@OpenWrt:/elp# > ------------------------------------------------------------------------------ > Monitor your physical, virtual and cloud infrastructure from a single > web console. Get in-depth insight into apps, servers, databases, vmware, > SAP, cloud infrastructure, etc. Download 30-day Free Trial. > Pricing starts from $795 for 25 servers or applications! > http://p.sf.net/sfu/zoho_dev2dev_nov > _______________________________________________ > Ocf-linux-users mailing list > Ocf...@li... > https://lists.sourceforge.net/lists/listinfo/ocf-linux-users -- David McCullough, dav...@mc..., Ph:+61 734352815 McAfee - SnapGear http://www.mcafee.com http://www.uCdot.org |
|
From: anand r. <one...@ya...> - 2012-11-27 06:43:16
|
Hi, I am encountering a crash in OCF, when I start a multiple SSL sessions. Please find the attached crash log with this mail. My environment: Linux kernel version 3.2.26, OpenSSL version 1.0.0g OCF linux 20120127 release. My setup: I am running two servers on a PC using below commands openssl s_server -accept 443 -cert evm1gwcert.pem -key evm1gwkey.pem -ssl3 -WWW openssl s_server -accept 446 -cert evm4gwcert.pem -key evm4gwkey.pem -ssl3 -WWW From my board I am starting a client using below command openssl s_time -connect 192.168.1.100:443 -www /cam1.mp4 -new -time 7200 -ssl3 -cipher HIGH & The above session is working fine. But when I start a second session openssl s_time -connect 192.168.1.100:446 -www /cam4.mp4 -new -time 7200 -ssl3 -cipher HIGH & I am observing a crash in OCF, If I unload the cryptodev module I am not observing any issue. Please help. Thanks, Anand Rao |
|
From: nikos k. <kar...@wi...> - 2012-11-05 15:59:48
|
Hello!
I have some questions concerning the openssl configuration option --with-cryptodev-digests.
1. Does the option --with-cryptodev-digests is necessary only for MD5/SHA hardware acceleration? 2. In addition by applying the openssl-0.9.8r.patch (in order to use the OCF from openssl) i had some compilation problems with the option --with-cryptodev-digests.The reasons have to do with some inactive pieces of code (#if 0) inside of some files of openssl.
For example in fileopenssl-0.9.8r\crypto\engine\eng_cryptodev.c at line 146#if 0static struct { int id; int nid;} digests[] = { { CRYPTO_SHA1_HMAC, NID_hmacWithSHA1, }, { CRYPTO_RIPEMD160_HMAC, NID_ripemd160, }, { CRYPTO_MD5_KPDK, NID_undef, }, { CRYPTO_SHA1_KPDK, NID_undef, }, { CRYPTO_MD5, NID_md5, }, { CRYPTO_SHA1, NID_undef, }, { 0, NID_undef, },};#endif
there is a piece of code inside at #if 0In order to compile with --with-cryptodev-digests i replace the #if 0 with #ifdef USE_CRYPTODEV_DIGESTS Is this the suitable procedure for compilation with --with-cryptodev-digests? Why openssl has these pieces of code inactive?
3. Also with --with-cryptodev-digests there are some reported problems e.g.http://sourceforge.net/mailarchive/forum.php?forum_name=ocf-linux-users&max_rows=25&style=nested&viewmonth=200805
Some problems i encountered also by myselfBy run the comand
# openssl x509 -in usercert.pem -signkey userkey.pem -out cert.crti take the error:
Getting Private key5480:error:0606B06E:digital envelope routines:EVP_SignFinal:wrong public key type:p_sign.c:99:5480:error:0D0C3006:asn1 encoding routines:ASN1_item_sign:EVP lib:a_sign.c:281:
By removing the option --with-cryptodev-digests this error was disappeared.
What is the directives concerning the --with-cryptodev-digests?Is it stable? How we can overcome such problems (EVP_SignFinal:wrong public key type)?
Thanks a lot! |
|
From: David M. <dav...@mc...> - 2012-11-01 23:18:50
|
Jivin Kim Phillips lays it down ... > On Thu, 1 Nov 2012 11:55:29 +0200 > nikos karag <kar...@wi...> wrote: > > > > > Hello! > > I'm currently deploy the OCF with talitos drives for Freescale SEC Engine utilization. > > I made some openssl speed tests concerning sha2 algorithms and it seems that there is no gain from SEC engine. > > Looking at the sources of OCF it seems that the used talitos version is old (2006 for SEC 2.1) and doesn't support sha2 algorithms. > > Searching at web we can find new version of talitos e.g. > > http://svn.dd-wrt.com:8000/browser/src/linux/universal/linux-3.3/drivers/crypto/talitos.c?rev=19208 > > My question is when the OCF will ??nvolve a new talitos version and also > > how i can do that by my own? > > Thanks in advance! > > IIRC, you should be able to use OCF's cryptosoft module to redirect > crypto requests to the mainline linux kernel driver. Don't forget > to disable CONFIG_OCF_TALITOS. That is correct. If you have a little driver experience it may not be too hard to add the sha2 support to the existing driver, but I haven't looked at it at all so I may be way off base, Cheers, Davidm -- David McCullough, dav...@mc..., Ph:+61 734352815 McAfee - SnapGear http://www.mcafee.com http://www.uCdot.org |
|
From: Kim P. <kim...@fr...> - 2012-11-01 21:49:22
|
On Thu, 1 Nov 2012 11:55:29 +0200 nikos karag <kar...@wi...> wrote: > > Hello! > I'm currently deploy the OCF with talitos drives for Freescale SEC Engine utilization. > I made some openssl speed tests concerning sha2 algorithms and it seems that there is no gain from SEC engine. > Looking at the sources of OCF it seems that the used talitos version is old (2006 for SEC 2.1) and doesn't support sha2 algorithms. > Searching at web we can find new version of talitos e.g. > http://svn.dd-wrt.com:8000/browser/src/linux/universal/linux-3.3/drivers/crypto/talitos.c?rev=19208 > My question is when the OCF will ιnvolve a new talitos version and also > how i can do that by my own? > Thanks in advance! IIRC, you should be able to use OCF's cryptosoft module to redirect crypto requests to the mainline linux kernel driver. Don't forget to disable CONFIG_OCF_TALITOS. Kim |
|
From: nikos k. <kar...@wi...> - 2012-11-01 10:08:09
|
Hello! I'm currently deploy the OCF with talitos drives for Freescale SEC Engine utilization. I made some openssl speed tests concerning sha2 algorithms and it seems that there is no gain from SEC engine. Looking at the sources of OCF it seems that the used talitos version is old (2006 for SEC 2.1) and doesn't support sha2 algorithms. Searching at web we can find new version of talitos e.g. http://svn.dd-wrt.com:8000/browser/src/linux/universal/linux-3.3/drivers/crypto/talitos.c?rev=19208 My question is when the OCF will ιnvolve a new talitos version and also how i can do that by my own? Thanks in advance! |
|
From: David M. <dav...@mc...> - 2012-06-21 23:56:32
|
Jivin Ajay Matai lays it down ... > At this point, I am wondering if it is even possible to use OCF SHA1 for any buffers greater than 32K? > If I call single CIOCCRYPT with 32K data block that works fine. > > If I break the same 32K block into 2 of 16k each and call CIOCCRYPT in a rolling fashion - the result is total garbage. Yes, I am not sure if it's possible myself, but I will look into it when I get a chance, just been very busy this week. > Also, not able to get anything bigger than 32K block working: get a ioctl: Invalid argument error. Yes, that limit is imposed by the OCF API. Cheers, Davidm > -----Original Message----- > From: Ajay Matai > Sent: Tuesday, June 19, 2012 4:02 PM > To: 'ocf...@li...' > Subject: Computing SHA1 for large files > > Hello, > I am a beginner at OCF interface. I have been trying to compute SHA1 hash for a large file (say 2GB). > > I thought, I could read the file say 8192 sized block at a time, call CIOCCRYPT with updated buffer. > In the end, call CIOCCRYPT one last time with src=NULL and len=0. > I should be able to get the mac back in the buffer pointed by mac. > > Tried it but this doesn't seem to work. What is the right way of working with large files and OCF framework. > > I know very basic question but any amount of googling and stack-overflowing didn't help. > > Thanks! > -ajay > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Ocf-linux-users mailing list > Ocf...@li... > https://lists.sourceforge.net/lists/listinfo/ocf-linux-users > > -- David McCullough, dav...@mc..., Ph:+61 734352815 McAfee - SnapGear http://www.mcafee.com http://www.uCdot.org |
|
From: Ajay M. <aj...@sy...> - 2012-06-21 19:02:43
|
At this point, I am wondering if it is even possible to use OCF SHA1 for any buffers greater than 32K? If I call single CIOCCRYPT with 32K data block that works fine. If I break the same 32K block into 2 of 16k each and call CIOCCRYPT in a rolling fashion - the result is total garbage. Also, not able to get anything bigger than 32K block working: get a ioctl: Invalid argument error. Any insight will be very helpful. Thanks, --ajay -----Original Message----- From: Ajay Matai Sent: Tuesday, June 19, 2012 4:02 PM To: 'ocf...@li...' Subject: Computing SHA1 for large files Hello, I am a beginner at OCF interface. I have been trying to compute SHA1 hash for a large file (say 2GB). I thought, I could read the file say 8192 sized block at a time, call CIOCCRYPT with updated buffer. In the end, call CIOCCRYPT one last time with src=NULL and len=0. I should be able to get the mac back in the buffer pointed by mac. Tried it but this doesn't seem to work. What is the right way of working with large files and OCF framework. I know very basic question but any amount of googling and stack-overflowing didn't help. Thanks! -ajay |
|
From: Ajay M. <aj...@sy...> - 2012-06-20 17:08:55
|
Thanks David. As it turns out, I am unable to use OpenSSL for this purpose. An example of how to SHA1 for large files would be great help. I have looked at OpenSSL code eng_cryptodev.c, it seems to buffer up the data and make one ioctl call (depending on EVP_MD_CTX_FLAG_ONESHOT flag) -- which doesn't make much sense to me. Thanks! --ajay -----Original Message----- From: David McCullough [mailto:dav...@mc...] Sent: Tuesday, June 19, 2012 6:02 PM To: Ajay Matai Cc: ocf...@li... Subject: Re: [Ocf-linux-users] Computing SHA1 for large files Jivin Ajay Matai lays it down ... > Thanks David. > > Openssl is definitely an option and I think, a good suggestion. > > Out of curiosity, I am wondering what would be involved working with OCF framework directly. > Just a gist would do. I honestly don't know and would have to go look at some code and figure it out, so I pass on that for now ;-) In theory you could dig out the code from openssl as an example. You will need to enable cryptodev digests in openssl to get OCF acceleration. The general rule is that user space acceleration of hashes is not worth the cost, so it is disabled by default. Its a config options to openssl, check the OCF doc, it should be in there, Cheers, Davidm > -----Original Message----- > From: David McCullough [mailto:dav...@mc...] > Sent: Tuesday, June 19, 2012 5:27 PM > To: Ajay Matai > Cc: ocf...@li... > Subject: Re: [Ocf-linux-users] Computing SHA1 for large files > > > Jivin Ajay Matai lays it down ... > > Hello, > > I am a beginner at OCF interface. I have been trying to compute SHA1 hash for a large file (say 2GB). > > > > I thought, I could read the file say 8192 sized block at a time, call CIOCCRYPT with updated buffer. > > In the end, call CIOCCRYPT one last time with src=NULL and len=0. > > I should be able to get the mac back in the buffer pointed by mac. > > > > Tried it but this doesn't seem to work. What is the right way of working with large files and OCF framework. > > > > I know very basic question but any amount of googling and stack-overflowing didn't help. > > I would recommend you use openssl (libcrpyto) to do this using the published openssl API's. Unless you are on a very resource constrained device which cannot afford to have openssl installed that is. > > The openssl API's are better documented, will let your application run on multiple different HW accelerated solutions including OCF, so it gives you a good plan going forward. > > You will need to load the cryptodev driver to use OCF with openssl. > > If openssl isn't an options let us know and I'll see what I can dig up > in way of an example talking directly to OCF, > > Cheers, > Davidm > > > -- > David McCullough, dav...@mc..., Ph:+61 734352815 > McAfee - SnapGear http://www.mcafee.com http://www.uCdot.org > > -- David McCullough, dav...@mc..., Ph:+61 734352815 McAfee - SnapGear http://www.mcafee.com http://www.uCdot.org |
|
From: David M. <dav...@mc...> - 2012-06-20 01:03:25
|
Jivin Ajay Matai lays it down ... > Thanks David. > > Openssl is definitely an option and I think, a good suggestion. > > Out of curiosity, I am wondering what would be involved working with OCF framework directly. > Just a gist would do. I honestly don't know and would have to go look at some code and figure it out, so I pass on that for now ;-) In theory you could dig out the code from openssl as an example. You will need to enable cryptodev digests in openssl to get OCF acceleration. The general rule is that user space acceleration of hashes is not worth the cost, so it is disabled by default. Its a config options to openssl, check the OCF doc, it should be in there, Cheers, Davidm > -----Original Message----- > From: David McCullough [mailto:dav...@mc...] > Sent: Tuesday, June 19, 2012 5:27 PM > To: Ajay Matai > Cc: ocf...@li... > Subject: Re: [Ocf-linux-users] Computing SHA1 for large files > > > Jivin Ajay Matai lays it down ... > > Hello, > > I am a beginner at OCF interface. I have been trying to compute SHA1 hash for a large file (say 2GB). > > > > I thought, I could read the file say 8192 sized block at a time, call CIOCCRYPT with updated buffer. > > In the end, call CIOCCRYPT one last time with src=NULL and len=0. > > I should be able to get the mac back in the buffer pointed by mac. > > > > Tried it but this doesn't seem to work. What is the right way of working with large files and OCF framework. > > > > I know very basic question but any amount of googling and stack-overflowing didn't help. > > I would recommend you use openssl (libcrpyto) to do this using the published openssl API's. Unless you are on a very resource constrained device which cannot afford to have openssl installed that is. > > The openssl API's are better documented, will let your application run on multiple different HW accelerated solutions including OCF, so it gives you a good plan going forward. > > You will need to load the cryptodev driver to use OCF with openssl. > > If openssl isn't an options let us know and I'll see what I can dig up in way of an example talking directly to OCF, > > Cheers, > Davidm > > > -- > David McCullough, dav...@mc..., Ph:+61 734352815 > McAfee - SnapGear http://www.mcafee.com http://www.uCdot.org > > -- David McCullough, dav...@mc..., Ph:+61 734352815 McAfee - SnapGear http://www.mcafee.com http://www.uCdot.org |
|
From: Ajay M. <aj...@sy...> - 2012-06-20 00:45:54
|
Thanks David. Openssl is definitely an option and I think, a good suggestion. Out of curiosity, I am wondering what would be involved working with OCF framework directly. Just a gist would do. Thanks! -----Original Message----- From: David McCullough [mailto:dav...@mc...] Sent: Tuesday, June 19, 2012 5:27 PM To: Ajay Matai Cc: ocf...@li... Subject: Re: [Ocf-linux-users] Computing SHA1 for large files Jivin Ajay Matai lays it down ... > Hello, > I am a beginner at OCF interface. I have been trying to compute SHA1 hash for a large file (say 2GB). > > I thought, I could read the file say 8192 sized block at a time, call CIOCCRYPT with updated buffer. > In the end, call CIOCCRYPT one last time with src=NULL and len=0. > I should be able to get the mac back in the buffer pointed by mac. > > Tried it but this doesn't seem to work. What is the right way of working with large files and OCF framework. > > I know very basic question but any amount of googling and stack-overflowing didn't help. I would recommend you use openssl (libcrpyto) to do this using the published openssl API's. Unless you are on a very resource constrained device which cannot afford to have openssl installed that is. The openssl API's are better documented, will let your application run on multiple different HW accelerated solutions including OCF, so it gives you a good plan going forward. You will need to load the cryptodev driver to use OCF with openssl. If openssl isn't an options let us know and I'll see what I can dig up in way of an example talking directly to OCF, Cheers, Davidm -- David McCullough, dav...@mc..., Ph:+61 734352815 McAfee - SnapGear http://www.mcafee.com http://www.uCdot.org |
|
From: David M. <dav...@mc...> - 2012-06-20 00:42:58
|
Jivin Ajay Matai lays it down ... > Hello, > I am a beginner at OCF interface. I have been trying to compute SHA1 hash for a large file (say 2GB). > > I thought, I could read the file say 8192 sized block at a time, call CIOCCRYPT with updated buffer. > In the end, call CIOCCRYPT one last time with src=NULL and len=0. > I should be able to get the mac back in the buffer pointed by mac. > > Tried it but this doesn't seem to work. What is the right way of working with large files and OCF framework. > > I know very basic question but any amount of googling and stack-overflowing didn't help. I would recommend you use openssl (libcrpyto) to do this using the published openssl API's. Unless you are on a very resource constrained device which cannot afford to have openssl installed that is. The openssl API's are better documented, will let your application run on multiple different HW accelerated solutions including OCF, so it gives you a good plan going forward. You will need to load the cryptodev driver to use OCF with openssl. If openssl isn't an options let us know and I'll see what I can dig up in way of an example talking directly to OCF, Cheers, Davidm -- David McCullough, dav...@mc..., Ph:+61 734352815 McAfee - SnapGear http://www.mcafee.com http://www.uCdot.org |
|
From: Ajay M. <aj...@sy...> - 2012-06-19 23:15:03
|
Hello, I am a beginner at OCF interface. I have been trying to compute SHA1 hash for a large file (say 2GB). I thought, I could read the file say 8192 sized block at a time, call CIOCCRYPT with updated buffer. In the end, call CIOCCRYPT one last time with src=NULL and len=0. I should be able to get the mac back in the buffer pointed by mac. Tried it but this doesn't seem to work. What is the right way of working with large files and OCF framework. I know very basic question but any amount of googling and stack-overflowing didn't help. Thanks! -ajay |
|
From: <job...@ao...> - 2012-04-25 06:57:57
|
http://www.krshna.me/wp-content/themes/TheStyle/mooney10000.html |
|
From: David M. <dav...@mc...> - 2012-02-09 04:25:03
|
Jivin Jan Just Keijser lays it down ... > hi all, > > I'm trying to use ocf for the first time - the concept looks great, and > I am very curious how the ocf drivers will perform compared to the > (latest) openssl assembly code. However, I cannot even get a simple > 'cryptotest' to run on my Fedora 14 laptop: It is unlikely t obe faster than the openssl assembly code unless you have a hardware crypto accelerator. OCF passes the crypto from openssl to the kernel for processing, just do that alone is a very expensive task, so in order to benefit, the kernel crypto must be faster than software by an order of magnitude. There are SMP cases when OCF+software can speed things up but it is unlikely you have this scenario if you are running from user space. > [root@beijaflor crypto-tools]# uname -a > Linux beijaflor 2.6.35.14-106.fc14.x86_64 #1 SMP Wed Nov 23 13:07:52 UTC > 2011 x86_64 x86_64 x86_64 GNU/Linux > [root@beijaflor crypto-tools]# lsmod | grep crypto > [root@beijaflor crypto-tools]# modprobe ocf > [root@beijaflor crypto-tools]# modprobe cryptosoft > [root@beijaflor crypto-tools]# modprobe crypto_null crypto_null is not for general use, it is a dummy driver that does nothing. Developers can use this to test the speed of all their code in the theoretical situation of crypto being zero cost. So it allows you to test the raw speed of your ipsec stack with no crypto (when talking to another similarly hacked ipsec stack). You do not want crypto_null. > [root@beijaflor crypto-tools]# modprobe ocf-bench > FATAL: Error inserting ocf_bench > (/lib/modules/2.6.35.14-106.fc14.x86_64/extra/ocf-bench.ko): Invalid > argument This is normal, ocf-bench is a speed test driver that always fails to load. > [root@beijaflor crypto-tools]# dmesg | tail -5 > [ 9440.770735] alg: No test for digest_null (digest_null-generic) > [ 9440.770760] alg: No test for compress_null (compress_null-generic) > [ 9460.475287] Crypto Speed tests > [ 9460.475327] OCF: testing ... > [ 9461.476315] OCF: 47784 requests of 1488 bytes in 1001 jiffies > (568.252 Mbps) The output of ocf-bench is really only of use to developers and crypto driver writers, so don't read much into that. > [root@beijaflor crypto-tools]# ls -al /dev/crypto > crw-r--r-- 1 root root 10, 70 Feb 6 16:04 /dev/crypto > [root@beijaflor crypto-tools]# ./cryptotest > cryptotest: /dev/crypto: No such device > > what am I doing wrong here? also, 'openssl engine -v' will not list the > cryptodev engine You need to load the "cryptodev" driver as well. modprobe cryptodev You will not have a cryptodev driver unless you patched your kernel. Read through the README carefully and it will explain why this is and why you probably do not want to be doing what you are doing. Without hardware acceleration, there is little point calling into OCF from user space. > Final question: is/will there be support for the cryptodev engine in > openssl 1.0+ ? It should all be there and ready to go. I believe the --with-cryptodev option is still used to enable it in the latest openssl releases, Cheers, Davidm -- David McCullough, dav...@mc..., Ph:+61 734352815 McAfee - SnapGear http://www.mcafee.com http://www.uCdot.org |
|
From: Jan J. K. <ja...@ni...> - 2012-02-06 15:34:23
|
hi all, I'm trying to use ocf for the first time - the concept looks great, and I am very curious how the ocf drivers will perform compared to the (latest) openssl assembly code. However, I cannot even get a simple 'cryptotest' to run on my Fedora 14 laptop: [root@beijaflor crypto-tools]# uname -a Linux beijaflor 2.6.35.14-106.fc14.x86_64 #1 SMP Wed Nov 23 13:07:52 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux [root@beijaflor crypto-tools]# lsmod | grep crypto [root@beijaflor crypto-tools]# modprobe ocf [root@beijaflor crypto-tools]# modprobe cryptosoft [root@beijaflor crypto-tools]# modprobe crypto_null [root@beijaflor crypto-tools]# modprobe ocf-bench FATAL: Error inserting ocf_bench (/lib/modules/2.6.35.14-106.fc14.x86_64/extra/ocf-bench.ko): Invalid argument [root@beijaflor crypto-tools]# dmesg | tail -5 [ 9440.770735] alg: No test for digest_null (digest_null-generic) [ 9440.770760] alg: No test for compress_null (compress_null-generic) [ 9460.475287] Crypto Speed tests [ 9460.475327] OCF: testing ... [ 9461.476315] OCF: 47784 requests of 1488 bytes in 1001 jiffies (568.252 Mbps) [root@beijaflor crypto-tools]# ls -al /dev/crypto crw-r--r-- 1 root root 10, 70 Feb 6 16:04 /dev/crypto [root@beijaflor crypto-tools]# ./cryptotest cryptotest: /dev/crypto: No such device what am I doing wrong here? also, 'openssl engine -v' will not list the cryptodev engine Final question: is/will there be support for the cryptodev engine in openssl 1.0+ ? TIA, JJK |
|
From: David M. <dav...@mc...> - 2012-01-27 01:33:33
|
Hi all,
A new release that adds linux-3 support and fixes bugs in the scatterlist
management of a few drivers.
http://sourceforge.net/projects/ocf-linux/files/ocf-linux/20120127/
Cheers,
Davidm
--
David McCullough, dav...@mc..., Ph:+61 734352815
McAfee - SnapGear http://www.mcafee.com http://www.uCdot.org
|
|
From: David M. <dav...@mc...> - 2012-01-27 01:21:27
|
Hi Herman, Thanks for the these. Both of the changes are in the new version I just uploaded to sourceforge. http://sourceforge.net/projects/ocf-linux/files/ocf-linux/20120127/ Let me know if I messed any of it up :-) Thanks, Davidm Jivin Schuurman, Herman lays it down ... > Hi David, > > It looks like the OCF cryptosoft driver is not terminating scatterlists correctly. The problem shows up if a crypto API hardware driver relies on sg_next() to return NULL at the end of a scatterlist chain, eventually leading to a bad pointer reference if the end is not marked correctly. > > The following change to crypto/ocf/cryptosoft.c looks like it resolves the problem: > > *** crypto/ocf/cryptosoft.c 2011-11-18 16:00:50.399693999 -0600 > --- crypto/ocf/cryptosoft.c 2012-01-25 11:45:48.637623644 -0600 > *************** > *** 814,819 **** > --- 814,820 ---- > sg_len, offset_in_page(crp->crp_buf + skip)); > sg_num = 1; > } > + sg_mark_end(&req->sg[sg_num-1]); > > switch (sw->sw_type & SW_TYPE_ALG_AMASK) { > > This marks the last sg entry written with sg_mark_end(). > > Best regards, > > Herman Schuurman > > > Jivin Schuurman, Herman lays it down ... > Hi David, > > The current version of cryptotest from the crypto-tools-20100325.tar.gz package only tests the sha256_hmac, and not the md5_hmac, sha1_hmac, sha384_hmac, and sha512_hmac (if available). This happens because the authkey length settings don't match between crypto/ocf/cryptodev.c and cryptotest.c. > > Crypto/ocf/cryptodev.c uses the following settings for authkey, based on the operation (see cryptodev_ioctl()): > > CRYPTO_MD5_HMAC 16 > CRYPTO_SHA1_HMAC 20 > CRYPTO_SHA2_256_HMAC 32 > CRYPTO_SHA2_384_HMAC 48 > CRYPTO_SHA2_512_HMAC 64 > > Cryptotest.c uses the alg structure table to compute the authkey length: > > { "md5", 1, 8, 0, 0, 16, CRYPTO_MD5 }, > { "md5_hmac", 1, 8, 1, 64, 16, CRYPTO_MD5_HMAC }, > { "sha1", 1, 8, 0, 0, 20, CRYPTO_SHA1 }, > { "sha1_hmac", 1, 1, 1, 64, 20, CRYPTO_SHA1_HMAC }, > { "sha256", 1, 8, 0, 0, 32, CRYPTO_SHA2_256 }, > { "sha256_hmac", 1, 1, 1, 64, 32, CRYPTO_SHA2_256_HMAC }, > { "sha384", 1, 8, 0, 0, 48, CRYPTO_SHA2_384 }, > { "sha384_hmac", 1, 1, 1, 64, 48, CRYPTO_SHA2_384_HMAC }, > { "sha512", 1, 8, 0, 0, 64, CRYPTO_SHA2_512 }, > { "sha512_hmac", 1, 1, 1, 64, 64, CRYPTO_SHA2_512_HMAC }, > > All _hmac entries show a minkeylen/maxkeylen value of 1/64. This causes runtest() to pass a keylen of (1+64)/2 = 32, which only works for the sha256_hmac. Changing the table entries in cryptotest.c to: > > { "md5", 1, 8, 0, 0, 16, CRYPTO_MD5 }, > { "md5_hmac", 1, 8, 16, 16, 16, CRYPTO_MD5_HMAC }, > { "sha1", 1, 8, 0, 0, 20, CRYPTO_SHA1 }, > { "sha1_hmac", 1, 1, 20, 20, 20, CRYPTO_SHA1_HMAC }, > { "sha256", 1, 8, 0, 0, 32, CRYPTO_SHA2_256 }, > { "sha256_hmac", 1, 1, 32, 32, 32, CRYPTO_SHA2_256_HMAC }, > { "sha384", 1, 8, 0, 0, 48, CRYPTO_SHA2_384 }, > { "sha384_hmac", 1, 1, 48, 48, 48, CRYPTO_SHA2_384_HMAC }, > { "sha512", 1, 8, 0, 0, 64, CRYPTO_SHA2_512 }, > { "sha512_hmac", 1, 1, 64, 64, 64, CRYPTO_SHA2_512_HMAC }, > > allows cryptotest to test the other *_hmacs too. > > Best regards, > > Herman Schuurman > > > -- David McCullough, dav...@mc..., Ph:+61 734352815 McAfee - SnapGear http://www.mcafee.com http://www.uCdot.org |
|
From: David M. <dav...@mc...> - 2012-01-26 22:52:04
|
Jivin Schuurman, Herman lays it down ...
> Hi David,
>
> It looks like the OCF cryptosoft driver is not terminating scatterlists correctly. The problem shows up if a crypto API hardware driver relies on sg_next() to return NULL at the end of a scatterlist chain, eventually leading to a bad pointer reference if the end is not marked correctly.
>
> The following change to crypto/ocf/cryptosoft.c looks like it resolves the problem:
>
> *** crypto/ocf/cryptosoft.c 2011-11-18 16:00:50.399693999 -0600
> --- crypto/ocf/cryptosoft.c 2012-01-25 11:45:48.637623644 -0600
> ***************
> *** 814,819 ****
> --- 814,820 ----
> sg_len, offset_in_page(crp->crp_buf + skip));
> sg_num = 1;
> }
> + sg_mark_end(&req->sg[sg_num-1]);
>
> switch (sw->sw_type & SW_TYPE_ALG_AMASK) {
>
> This marks the last sg entry written with sg_mark_end().
I think you are right, beats me how this survived for so long.
I'll get this incorporated and look for other users,
Thanks,
Davidm
--
David McCullough, dav...@mc..., Ph:+61 734352815
McAfee - SnapGear http://www.mcafee.com http://www.uCdot.org
|
4 messages has been excluded from this view by a project administrator.
