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

[Patrick Lamaizière]

Le Wed, 10 Dec 2008 14:50:51 -0800,
Sam Leffler <sam at freebsd.org> a écrit :

Hello,

> > 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). 

That is the easiest way to do, i think.

> 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.

Ok, thank you. I will try to tests 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.

I don't know enough the kernel to make a revolution. Anyway I can make
some evolutions and try to help. Is there someone working on the
crypto framework ?

Regards.