From owner-freebsd-stable@FreeBSD.ORG Mon Jan 26 13:43:31 2004 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D26BA16A4CE; Mon, 26 Jan 2004 13:43:31 -0800 (PST) Received: from smtp3.sentex.ca (smtp3.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id DA35643D39; Mon, 26 Jan 2004 13:43:29 -0800 (PST) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smtp3.sentex.ca (8.12.10/8.12.10) with ESMTP id i0QLhOUE079205; Mon, 26 Jan 2004 16:43:24 -0500 (EST) (envelope-from mike@sentex.net) Received: from simian.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.12.9p2/8.12.9) with ESMTP id i0QLhRNq004422; Mon, 26 Jan 2004 16:43:27 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <6.0.1.1.0.20040126164121.06ee1f50@209.112.4.2> X-Sender: mdtpop@209.112.4.2 (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Mon, 26 Jan 2004 16:43:14 -0500 To: Robert Watson From: Mike Tancsa In-Reply-To: References: <20040126153430.GA230@e-card.bg> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by amavisd-new cc: stable@freebsd.org Subject: Re: FreeBSD + Rainbow Cryptoswift X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2004 21:43:31 -0000 At 01:25 PM 26/01/2004, Robert Watson wrote: > > > > I took a look at those cards (vpn1201 and vpn1211). They don't seem to > > have AES support and only support 2-8 RSA connections/sec. Rainbow say > > that their cards support 1000 RSA connections/sec which is quite > > astonishing. The vpn1401 and vpn1411 seem to have better performance > > but as you said the hifn(4) driver support is broken for those :( > >Poul-Henning recently sent me some performance numbers from his initial >work to hook GEOM up to the AES support in the crypto framework using the >VPN1401/1411. He didn't seem to report any brokenness in the driver in >-CURRENT. The support may not yet have been MFC'd to -STABLE yet, >however. I forgot the steps I used to re-create the problem. Perhaps phk can try it on 5.x to see if the problem is there as well. Here is what I posed on the soekris list --------------- I can also reproduce it without too much trouble doing something like the following. Login via ssh with a non supported cipher like blowfish. Login a second time with a supported cipher e.g. 3des). Then issue something like the following from the blowfish session. openssl enc -des3 -in big -k p | ssh mdtancsa@192.168.43.26 "cat - > /usr/home/mdtancsa/b.out" where the file big is some very large file. It seems to take a while (5 or 6 iterations at first of a file 914,767,872 which was initially created with cat /dev/urandom > ) but then it seems to be fairly easy to reproduce happening a few times during the big session. Running truss on the openssl pid, .... write(1,0x80ac000,16384) = 16384 (0x4000) read(0x4,0x80b2000,0x4000) = 16384 (0x4000) ioctl(5,CIOCCRYPT,0xbfbff334) = 0 (0x0) ioctl(5,CIOCCRYPT,0xbfbff334) = 0 (0x0) ioctl(5,CIOCCRYPT,0xbfbff334) = 0 (0x0) ioctl(5,CIOCCRYPT,0xbfbff334) = 0 (0x0) write(1,0x80ac000,16384) = 16384 (0x4000) read(0x4,0x80b2000,0x4000) = 16384 (0x4000) ioctl(5,CIOCCRYPT,0xbfbff334) = 0 (0x0) ioctl(5,CIOCCRYPT,0xbfbff334) = 0 (0x0) ioctl(5,CIOCCRYPT,0xbfbff334) = 0 (0x0) ioctl(5,CIOCCRYPT,0xbfbff334) = 0 (0x0) ... and then it just stalls. If I then hit enter in the 3des encrypted ssh session or do something that talks to /dev/crypto, it goes again for a seeming random period of time. It seems to pick up exactly where it should. The next lines being, write(1,0x80ac000,16384) = 16384 (0x4000) read(0x4,0x80b2000,0x4000) = 16384 (0x4000) ioctl(5,CIOCCRYPT,0xbfbff334) = 0 (0x0) ioctl(5,CIOCCRYPT,0xbfbff334) = 0 (0x0) ioctl(5,CIOCCRYPT,0xbfbff334) = 0 (0x0) ioctl(5,CIOCCRYPT,0xbfbff334) = 0 (0x0) write(1,0x80ac000,16384) = 16384 (0x4000) read(0x4,0x80b2000,0x4000) = 16384 (0x4000) ioctl(5,CIOCCRYPT,0xbfbff334) = 0 (0x0) ioctl(5,CIOCCRYPT,0xbfbff334) = 0 (0x0) ioctl(5,CIOCCRYPT,0xbfbff334) = 0 (0x0) ioctl(5,CIOCCRYPT,0xbfbff334) = 0 (0x0) write(1,0x80ac000,16384) = 16384 (0x4000) read(0x4,0x80b2000,0x4000) = 16384 (0x4000) ioctl(5,CIOCCRYPT,0xbfbff334) = 0 (0x0) ioctl(5,CIOCCRYPT,0xbfbff334) = 0 (0x0) ioctl(5,CIOCCRYPT,0xbfbff334) = 0 (0x0) ioctl(5,CIOCCRYPT,0xbfbff334) = 0 (0x0) write(1,0x80ac000,16384) = 16384 (0x4000) and then stalls again. I dont have debugging symbols built, but attaching to it shows (gdb) bt #0 0x2825a540 in write () from /usr/lib/libc.so.4 #1 0x28259fb2 in __swrite () from /usr/lib/libc.so.4 #2 0x2825815d in __sflush () from /usr/lib/libc.so.4 #3 0x282580c5 in fflush () from /usr/lib/libc.so.4 #4 0x28254e8e in __sfvwrite () from /usr/lib/libc.so.4 #5 0x281fc4cc in fwrite () from /usr/lib/libc.so.4 #6 0x28191dde in BIO_s_file () from /usr/lib/libcrypto.so.3 #7 0x2819f34b in BIO_write () from /usr/lib/libcrypto.so.3 #8 0x2812fb66 in BIO_f_cipher () from /usr/lib/libcrypto.so.3 #9 0x2819f34b in BIO_write () from /usr/lib/libcrypto.so.3 #10 0x80619eb in TXT_DB_get_by_index () #11 0x8066806 in TXT_DB_get_by_index () #12 0x8066574 in TXT_DB_get_by_index () #13 0x8053d3a in TXT_DB_get_by_index () I am happy to do any grunt work to track this down. ---Mike