Le Wed, 10 Dec 2008 14:50:51 -0800, Sam Leffler <s...@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. _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
