Re: /dev/crypto
Thor Lancelot Simon <[email protected]> Mon, 1 Dec 2014 16:56:11 -0500
| Newsgroups | gmane.os.netbsd.devel.crypto |
|---|---|
| Message-ID | <[email protected]> |
On Thu, Nov 27, 2014 at 11:02:41AM +0000, Patrick Welche wrote: > > His conclusion in > > http://mail-index.netbsd.org/tech-crypto/2005/05/29/msg000362.html Note the referenced message is from 2005. > is: > > For what it's worth, while working with both sides of /dev/crypto > (writing some applications and adding a hw-acceleration backend), I've > developed the strong impression that the /dev/crypto interface is > something of an afterthought or testing interface, and that the only > "first class" interface to crypto(4) is the kernel interface. That may have been true in 2005, when there was no way to do asynchronous requests. I don't think it's true now. At Coyote Point we put a lot of work into enhancing the /dev/crypto interface (as well as the underlying kernel subsystem) to allow high rate use from userspace. We did this by adding request types for asynchronous request submission and multiple request retrieval, while otherwise retaining backwards compatibility with the old interface. Unfortunately, since most applications use OpenSSL with its inherent limitations (in particular, that its core SSL code and its ENGINE interface don't allow any way to wait on asynchronous resources of any kind) this has not proven terribly useful to others. One thing that is particularly frustrating to me is that neither the FreeBSD nor Linux maintainers of the relevant code have picked up our enhancements, though I did point them out to them at the time. While at Coyote Point I also got the source code to a very high performance enhanced version of OpenSSL (which had support for async requests added) open-sourced by its author. This was NetOctave's SSL library which used their proprietary device driver interface, not /dev/crypto, but the core modifications (and the whitepaper that described them) were certainly relevant; unfortunately this (efficient support for coprocessor style accellerators) is a path the OpenSSL team made pretty clear they were not interested in walking. Too bad. *Sigh*. Thor