cvs commit: src/sys/dev/glxsb glxsb.c glxsb_hash.c

[Pawel Jakub Dawidek]

On Mon, Aug 11, 2008 at 01:06:00PM -0400, John Baldwin wrote:
> On Monday 11 August 2008 04:41:08 am Pawel Jakub Dawidek wrote:
> > pjd         2008-08-11 08:41:08 UTC
> > 
> >   FreeBSD src repository
> > 
> >   Modified files:
> >     sys/dev/glxsb        glxsb.c glxsb_hash.c 
> >   Log:
> >   SVN rev 181593 on 2008-08-11 08:41:08Z by pjd
> >   
> >   - Convert sc_sessions_mtx mutex to a rwlock, so in the fast path
> >     (glxsb_process()) we don't block others when looking for our session.
> >   - Simplify the loop responsible for freeing sessions on detach.
> >   - No need to drop a lock around malloc(M_NOWAIT).
> >   - Treat ses_used as boolean.
> >   - Avoid gotos where possible.
> >   - Various style(9) fixes.
> >   
> >   Reviewed by:    philip, Patrick Lamaiziere <patfbsd at davenulle.org>
> 
> Would it be worthwhile to abstract the session handling out of padlock(4) and 
> glxsb(4)?  Are there other CPUs with embedded crypto that will need their own 
> drivers that having the abstraction would make writing a driver easier?

There is still a lot of work to do. Session handling is probably a good
candidate for abstraction, but what I don't like the most is that every
single driver have to implement both encryption and hash algorithms to
be able to work with IPsec, etc. That's why both padlock and glxsb have
software implementation of hash algorithms and lie about supporting
them. The opencrypto framework should return a driver that supports
both algorithm that consumer is looking for, but if can't find one, it
should propose one driver for encryption and another driver for hash
calculations and hide this separation from the consumer.

The are other issues too. For example some drivers support only one
order of operations (encryption and hash) and we have three:

Authenticate-then-Encrypt
Encrypt-and-Authenticate
Encrypt-then-Authenticate

The order should be also registered by the driver to the opencrypto
framework and if there is no driver with the requested order, opencrypto
should handle reordering by itself.

Mind you every one of the three most popular crypto protocols (IPsec,
SSL, SSH) uses different order of operations.

Another issue (pointed out by Patrick) is that glxsb only supports
AES with 128 bits key and currently one can only register AES support,
which implies all key lengths. BTW. Solution for glxsb for now is
probably handling 192 and 256 keys in software and not returing EINVAL.

-- 
Pawel Jakub Dawidek                       http://www.wheel.pl
pjd at FreeBSD.org                           http://www.FreeBSD.org
FreeBSD committer                         Am I Evil? Yes, I Am!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/cvs-src/attachments/20080812/fafe5537/attachment.pgp