crypto(9) choose another driver if we cannot open a session on
patfbsd at davenulle.org
Fri Dec 12 14:57:39 PST 2008
Le Wed, 10 Dec 2008 14:50:51 -0800,
Sam Leffler <sam at freebsd.org> a écrit :
> > 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 ?
More information about the freebsd-hackers