Re: HIFN/7955 Soekris 1401 openssl problem
> >The problem is, nothing else seems to use it. Ive been trying with > >sendmail/ssl and with apache/ssl. The card uses /dev/crypto, which exists, > >and I can make openssl load the cryptodev engine. But even a command like > >'openssl speed -engine cryptodev' doesnt use the card for any algorithm. > >Sendmail and apache are linked with libcrypto. > > Only certain commands /encryption schemes will use it in openssl. eg > > /usr/bin/openssl enc -des3 -in big.txt -k pass -out big.txt.enc > > Also, for ipsec you need to use FAST_IPSEC if you want to use it for > IPSEC stuff. > > You are using the base openssl right ? I dont want to use it for IPSEC. One of my collegues is, and thats working fine also. I want to use it for TLS/SSL acceleration in sendmail. I linked sendmail against the base openssl (libcrypto and libssl). When using mozilla to send a mail it negotiates the following encryption scheme: DHE-RSA-AES256-SHA. Ive also used Kmail and outlook, which negotiated slightly different schemes, but also didnt work. And I forced a whole myriad of schemes, from simple to complicated, through apache, and none of them worked. Is there a way to get hardware acceleration for sendmail TLS/SSL? Maybe get a different card? Cor ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HIFN/7955 Soekris 1401 openssl problem
At 03:59 AM 17/07/2004, Cor Bosman wrote: I dont want to use it for IPSEC. One of my collegues is, and thats working fine also. I want to use it for TLS/SSL acceleration in sendmail. I linked sendmail against the base openssl (libcrypto and libssl). When using mozilla to send a mail it negotiates the following encryption scheme: DHE-RSA-AES256-SHA. Ive also used Kmail and outlook, which If you look at the man pages for the hifn card and for crypto, it will list what the card supports for encryption, and what crypto supports Depending on hardware being present, the following symmetric and asymmet- ric cryptographic features are potentially available from /dev/crypto: CRYPTO_DES_CBC CRYPTO_3DES_CBC CRYPTO_BLF_CBC CRYPTO_CAST_CBC CRYPTO_SKIPJACK_CBC CRYPTO_MD5_HMAC CRYPTO_SHA1_HMAC CRYPTO_RIPEMD160_HMAC CRYPTO_MD5_KPDK CRYPTO_SHA1_KPDK CRYPTO_AES_CBC CRYPTO_ARC4 CRYPTO_MD5 CRYPTO_SHA1 CRK_MOD_EXP CRK_MOD_EXP_CRT CRK_DSA_SIGN CRK_DSA_VERIFY CRK_DH_COMPUTE_KEY if its not listed there, it doesnt matter what card you have or what the card potentially can do. ---Mike ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HIFN/7955 Soekris 1401 openssl problem
> >When using mozilla to send a mail it negotiates the following encryption > >scheme: DHE-RSA-AES256-SHA. Ive also used Kmail and outlook, which > > > If you look at the man pages for the hifn card and for crypto, it will list > what the card supports for encryption, and what crypto supports > > Depending on hardware being present, the following symmetric and asymmet- > ric cryptographic features are potentially available from /dev/crypto: > >CRYPTO_DES_CBC >CRYPTO_3DES_CBC >CRYPTO_BLF_CBC >CRYPTO_CAST_CBC >CRYPTO_SKIPJACK_CBC >CRYPTO_MD5_HMAC >CRYPTO_SHA1_HMAC >CRYPTO_RIPEMD160_HMAC >CRYPTO_MD5_KPDK >CRYPTO_SHA1_KPDK >CRYPTO_AES_CBC >CRYPTO_ARC4 >CRYPTO_MD5 >CRYPTO_SHA1 >CRK_MOD_EXP >CRK_MOD_EXP_CRT >CRK_DSA_SIGN >CRK_DSA_VERIFY >CRK_DH_COMPUTE_KEY > > if its not listed there, it doesnt matter what card you have or what the > card potentially can do. Yeah, i figured this was the problem. The driver/card only registered the following schemes: RSA, DSA, DH, DES-CBC, DES-EDE3-CBC, AES-128-CBC If i understand you and the manual correctly, no matter what the card supports, crytodev only supports the list you mentioned above? How do you read such a list. Does that mean a scheme like DES-CBC-SHA could possibly be supported? Or can only the 2 seperate schemes of DES_CBC and SHA1 be accelerated? If the latter, is there a way to find out what schemes different cards will register before buying them? :) Some cards have their own engine, so are seperate from cryptodev.. right? Cor ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Fw: Re: Locking: kern/50827
Begin forwarded message: Date: Fri, 9 Jul 2004 23:01:27 -0400 From: Brian Fundakowski Feldman <[EMAIL PROTECTED]> To: Stephen Hurd <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] Subject: Re: Locking: kern/50827 On Sun, Jul 04, 2004 at 04:06:45PM -0600, Stephen Hurd wrote: > > Right, if you just make it cross-platform in the first place using > > higher- level primitives you don't have to worry what the specific > > kernel and operating system and file system you are using provides. > > It's my opinion tha there won't be other people adopting this API for > > file locking since it is by definition not meant to work like the > > standardized APIs. > > > > I don't think that there's no value in having more useful locking > > primitives, but they probably don't benefit much from being implemented > > in the kernel unless they conform to a portable API. I certainly always > > have my own various kernel modifications that I find useful, but aren't > > very standard :) > > This sounds a lot like "Well, there's no point in doing something better > since nobody else is doing it.". strlcpy() and friends are an example of > non-standard stuff that just Makes Sense(tm). If you're trying to create a new "standard", I think -standards or -arch is the more appropriate FreeBSD list. -- Brian Fundakowski Feldman \'[ FreeBSD ]''\ <> [EMAIL PROTECTED] \ The Power to Serve! \ Opinions expressed are my own. \,,\ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
linker_load_module(NULL, "modname", ...) from thread with no user process
Dear hackers,
there is problem when linker_load_module() is called from a kernel thread with
no associated user process, and it asks to load module by name, not by filename.
With such parameters it requires looking through device.hints file.
And vn_open() assumes that ndp->ni_cnd->cn_thread->td_proc is valid.
Any ideas how to solve this?
Here is a sample backtrace:
#8 0xc06ba0b3 in trap (frame=
{tf_fs = -1946419176, tf_es = 2106261520, tf_ds = 607387664, tf_edi =
-877233464, tf_esi = -1066365186, tf_ebp = -877234268, tf_isp = -877234312, tf_ebx =
2065, tf_edx = -877233504, tf_ecx = 0, tf_eax = -1051754144, tf_trapno = 12, tf_err =
0, tf_eip = -1068097648, tf_cs = 8, tf_eflags = 66182, tf_esp = -1056682528, tf_ss =
0})
at /usr/src/sys/i386/i386/trap.c:417
#9 0xc0561f90 in _mtx_lock_flags (m=0x0, opts=0,
file=0xc0708efe "/usr/src/sys/kern/vfs_subr.c", line=2065)
at /usr/src/sys/kern/kern_mutex.c:247
#10 0xc05c989c in vref (vp=0x811) at /usr/src/sys/kern/vfs_subr.c:2065
#11 0xc05c2438 in namei (ndp=0xcbb67aa0) at /usr/src/sys/kern/vfs_lookup.c:161
#12 0xc05d4f63 in vn_open_cred (ndp=0xcbb67aa0, flagp=0xcbb6797c, cmode=0,
cred=0xc14eae80, fdidx=0) at /usr/src/sys/kern/vfs_vnops.c:191
#13 0xc05d4cf3 in vn_open (ndp=0x0, flagp=0x0, cmode=0, fdidx=0)
at /usr/src/sys/kern/vfs_vnops.c:91
#14 0xc055ddc3 in linker_hints_lookup (
path=0xc074d160 "/boot/kernel;/boot/kernel;/boot/modules", pathlen=12,
modname=0xcbb67b68 "ng_tee", modnamelen=6, verinfo=0x0)
at /usr/src/sys/kern/kern_linker.c:1474
#15 0xc055e2da in linker_search_module (modname=0xcbb67b68 "ng_tee", modnamelen=6,
verinfo=0x0) at /usr/src/sys/kern/kern_linker.c:1594
#16 0xc055e49b in linker_load_module (kldname=0x0, modname=0xcbb67b68 "ng_tee",
parent=0x0, verinfo=0x0, lfpp=0xcbb67b64)
at /usr/src/sys/kern/kern_linker.c:1683
#17 0xc1b49aa6 in ng_make_node () from /boot/kernel/netgraph.ko
#18 0xc1b4bb61 in ng_mkpeer () from /boot/kernel/netgraph.ko
#19 0xc1b4d9b1 in ng_generic_msg () from /boot/kernel/netgraph.ko
#20 0xc1b4d615 in ng_apply_item () from /boot/kernel/netgraph.ko
#21 0xc1b4fa2b in ngintr () from /boot/kernel/netgraph.ko
#22 0xc05e236a in swi_net (dummy=0x0) at /usr/src/sys/net/netisr.c:255
#23 0xc0554d22 in ithread_loop (arg=0xc14f5400) at /usr/src/sys/kern/kern_intr.c:544
#24 0xc0553dd2 in fork_exit (callout=0xc0554ba0 , arg=0x0, frame=0x0)
at /usr/src/sys/kern/kern_fork.c:816
--
Totus tuus, Glebius.
GLEBIUS-RIPN GLEB-RIPE
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RFC: "-exit" option for find(1)
Peter Pentchev wrote: On Fri, Jul 16, 2004 at 05:28:57PM +0300, Peter Pentchev wrote: On Fri, Jul 16, 2004 at 11:58:07AM +0400, Denis Antrushin wrote: Alfred Perlstein wrote: I'm up too late, this doesn't work because find returns success whenever it successfully runs thought everything. Perhaps the primary change to just "-exit" which would make find exit successfully, and if the primary is never encountered (ie. our find logic never hits it) find would exit with a non-zero exit status? Ideas? Better ideas? The reason I want this is to avoid extracting a tarball over a directory that has files in it that are newer than the tarball. Neither tar nor find seem to make this easy... What about this: test -n "`find . -type f -newer ../src.tar.gz`" && echo hi I believe Alfred's problem with this is that it will still traverse the whole hierarchy even after a match is found. In some cases, the hierarchy may be huge, and if the match is within the first 100-200 files, well... :) I wonder if it wouldn't be a bit better to add to find(1) something like -maxmatches N, similar to Alfred's idea, but not limited to a single match? Well, I've just gone ahead and implemented it: say hello to the new -maxmatch N and -minmatch N primaries: -maxmatch n Always true; exits after printing out n matching filenames. If any -maxmatch primary is specified, it applies to the entire expression even if it would not normally be evaluated. -maxmatch 0 makes find exit immediately without performing any filesystem traversal. -minmatch n Always true; exits with a non-zero exit code if less than n matching filenames were printed out at the end of the search. If any -minmatch primary is specified, it applies to the entire expression even if it would not normally be evaluated. Thus, -maxmatch 1 would help in Alfred's case. Patch attached. I don't really like this because: a) It's global b) It is counting printed lines, while I might want to use -exec or something else c) It does not honour find(1)s [+-]n semantic How about two primaries: - -exit n, like proposed in the first post (sucess could be determined by a printed line or an -exec) - -match n, which is true when *this* primary has been matched n times so find [path] ... -match 1 -print -exit 0 will do the trick, while find [path] ... -match -10 -print will print the first 9 matches? -Oliver ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
KQueue and Threads?
Hello, I have a question about using KQueue() in multi-threaded situations. A couple months ago I wrote the KQueue support for Apache2/APR. I am now investigating a pseudo Event/Worker MPM to better handle KeepAlive Requests. (support for KQueue in Apache is available in our CVS HEAD and via an experimental patch in the FreeBSD Ports... Feedback would be nice.) For my example, say I have two threads. Thread A is in a kevent() waiting for events to happen on a set of FDs. Thread B has an FD that it would like to add to the KQueue that Thread A is using. What is the best way to get that FD into the KQueue, avoiding as much context switching as possible? Is it possible for Thread B to just call kevent w/ EV_ADD and Thread A will get proper notifications from that FD in the changed KQueue? I know this is possible with Linux's sys_epoll() implementation. Other threads can just add FDs to the epoll, and the thread waiting in the epoll will get notified of any activity on those new FDs, just like the existing FDs. If this is not possible with KQueue, I guess the best alternative is to have a pipe in the Set that Thread A is waiting on. Other threads will add their FD to a Queue, and then write to this pipe. That will awaken thread A, which then can add any FDs to it's pollset. That is less than ideal on a very busy server. An alternative is to set the timeout in Thread A very low. Say every 1/10 of a second, it would timeout, and add any outstanding FDs to the KQueue. Opinions? Thanks, -Paul Querna ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
