Re: glxsb(4) doesn't appear to be working for me (was: AMD Geode LX Security Block)

[Thor Lancelot Simon <tls%panix.com@localhost>]

On Fri, Oct 30, 2009 at 12:18:00PM -0400, Greg A. Woods wrote:
> At Thu, 29 Oct 2009 22:30:23 -0400, Thor Lancelot Simon 
> <tls%panix.com@localhost> wrote:
> Subject: Re: glxsb(4) doesn't appear to be working for me (was: AMD Geode LX 
> Security Block)
> > 
> > You may need to explicitly specify -engine cryptodev, and note that you
> > will not get *any* accelleration from openssl speed for any cipher
> > unless you specify it as an "evp" instead of by the shortcut name:
> > 
> > openssl speed -engine cryptodev -elapsed -evp aes-128-cbc
> 
> I'm not sure I understand.  None of the examples I saw on the NetBSD
> lists show this (and it's not explained at all in the manual page).

I can't say why people would post wrong examples to the NetBSD lists.  I
do often wish that if people didn't know what they were talking about,
they'd pipe down already with the "helpful" advice on the lists...

I can say why the manual page is wrong: OpenSSL manual pages in general
just plain suck.

Here is what is going on: the OpenSSL "engine" interface is jammed in at
their abstract-algorithm layer (fsvo "layer") which lies between their
SSL-record-handling layer and the raw encryption routines.  This layer
is called "EVP".

The openssl 'speed' utility calls the raw encryption routines when you
tell it to do a speed test for a cipher.  So the cryptodev engine never
sees the requests.  However, it calls the EVP routines when you tell it
to do a speed test for any other kind of algorithm, such as a hash
function like MD5 or SHA!  This can be extremely confusing.

The workaround is to trick it into thinking it's testing some other
kind of block-oriented algorithm by telling it to look up the cipher
*by its EVP* which forces it to use the EVP layer, so the engine layer
sees the requests.  This is what the -evp switch on the command line
accomplishes.

Thor