Date: Mon, 26 Jan 2004 16:43:14 -0500 From: Mike Tancsa <mike@sentex.net> To: Robert Watson <rwatson@freebsd.org> Cc: stable@freebsd.org Subject: Re: FreeBSD + Rainbow Cryptoswift Message-ID: <6.0.1.1.0.20040126164121.06ee1f50@209.112.4.2> In-Reply-To: <Pine.NEB.3.96L.1040126132256.11399V-100000@fledge.watson.o rg> References: <20040126153430.GA230@e-card.bg> <Pine.NEB.3.96L.1040126132256.11399V-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6.0.1.1.0.20040126164121.06ee1f50>