Re: /dev/crypto

[Patrick Welche <prlw1%cam.ac.uk@localhost>]

On Mon, Dec 01, 2014 at 04:56:11PM -0500, Thor Lancelot Simon wrote:
> 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.

Thank you for the encouragement to look again! Christos' patch to
cryptodev.c made the issue more obvious by returning ENOSPC.
The simplest program using /dev/crypto I could think of, was to write
an equivalent of gzip, using CRYPTO_GZIP_COMP synchronously.
With ENOMEM, I expected my malloc to fail rather than the ioctl.
With ENOSPC, it was simply the problem that one can be unlucky with
gzip, and a block can end up growing after "compression". I came
unstuck as I had tried dst_len = len. Using dst_len > len gives
me a working "openzip".

Cheers,

Patrick