crypto(9) choose another driver if we cannot open a session on it

[Sam Leffler]

Patrick Lamaizière wrote:
> Le Mon, 8 Dec 2008 21:21:55 +0100,
> Philip Paeps <philip at freebsd.org> a écrit :
>
> Hello,
>
>   
>> On 2008-12-07 22:45:51 (+0100), Patrick Lamaizière
>> <patfbsd at davenulle.org> wrote:
>>     
>>> I wrote a small patch to allow the crypto framework to choose
>>> another cryptographic driver if we cannot open a session on the
>>> driver.
>>>       
>> Very cool. :-)  I've been hacking on this too, mainly to get rid of
>> the code duplication that currently exists.
>>     
>
> Which code exactly? Yes I'm curious :-)
>
> I'm thinking about how to remove the need for a device to support all
> the algorithms when we open a session. By using a fake "crypto
> virtual device" to open and dispatch crypto requests to real devices or
> to cryptosoft. But i don't have any code to show yet.
>
> There is one thing I'm asking about crypto(9):
> - I doubt that the migration of a session is safe and I think that
> would be far easier to prevent a driver to unregister when there are
> some pending sessions on it? glxsb and padlock do not allow to
> unregister in this case. 
>
> I've looked quickly the code of geli or ipsec. If the crypto
> framework returns EAGAIN because the migration of the session, they
> restart a crypto_dispatch(crp) but the datas in crp->crp_buf can be
> corrupted by the previous crypto operation (IMHO, may be i've missed
> something)?
>   
This sounds like the session management layer I wanted to insert a while 
back.  It was a reason why I made the s/w driver into a pseudo device 
(so there'd be a handle).  I want to look at your mods but haven't had time.

As to unregister that was designed for devices like cardbus cards that 
might go away.  About the only way to simulate it today is to unload a 
driver module.  But it should work; if you see an issue we should try to 
fix it.  OTOH the limitations of the existing crypto code are dramatic 
and the rationale for maintaining the obsd api's (both in kernel and 
user space) are no longer valid.  It would be good to see someone take 
this stuff and overhaul it to do things like:

o add a session management layer that falls back to s/w when a device
   is incapable and when operations are more efficiently done in s/w (e.g
   ops too small to incur the dma setup/overhead)
o do load balancing over multiple devices
o support cpu resources as pseudo drivers (e.g. pin a thread to a cpu)
o replace the bogus fd session crud w/ device cloning

The linux folks have done some of this and there may be lessons to be 
learned from their efforts.  FWIW netbsd has some recent user api 
changes for doing async ops and batching to speedup openssl etc; if 
you're going to get into this stuff you might take a look.

    Sam