Re: crypto(9) choose another driver if we cannot open a session on it
Le Wed, 10 Dec 2008 14:50:51 -0800, Sam Leffler 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"
Re: crypto(9) choose another driver if we cannot open a session on it
Patrick Lamaizière wrote: Le Mon, 8 Dec 2008 21:21:55 +0100, Philip Paeps <[EMAIL PROTECTED]> a écrit : Hello, On 2008-12-07 22:45:51 (+0100), Patrick Lamaizière <[EMAIL PROTECTED]> 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 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: crypto(9) choose another driver if we cannot open a session on it
Le Mon, 8 Dec 2008 21:21:55 +0100, Philip Paeps <[EMAIL PROTECTED]> a écrit : Hello, > On 2008-12-07 22:45:51 (+0100), Patrick Lamaizière > <[EMAIL PROTECTED]> 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)? Thanks, regards. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: crypto(9) choose another driver if we cannot open a session on it
On 2008-12-07 22:45:51 (+0100), Patrick Lamaizière <[EMAIL PROTECTED]> 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. > That should not break anything. It would be nice to test it on a box with a > Geode LX CPU and a crypto device like a VPN1411 card. I don't have the > hardware but I've checked that we revert to the cryptosoft driver when using > ipsec and glxsb with AES key's length != 128 bits. I'll test that tonight. I think I've got a hifn card hiding somewhere near a soekris. Thanks! - Philip -- Philip PaepsPlease don't Cc me, I am [EMAIL PROTECTED] subscribed to the list. "Maybe you should loosen her clothing or something." -- Gaspode the wonder dog (Terry Pratchett, Moving Pictures) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
crypto(9) choose another driver if we cannot open a session on it
Hello, I wrote a small patch to allow the crypto framework to choose another cryptographic driver if we cannot open a session on the driver. The current version selects the driver that handles all the requested algorithms and with the less count of active sessions. But this is not enough, by example the glxsb(4) driver does not accept AES session with key's length != 128 bits. It rejects also HMAC algorithms if there is no AES encryption to do in the session (HMAC is done by software to make it works with ipsec). The other way to deal with this problem would be to implement in the glxsb driver software implementations for AES 192 et AES 256. (OpenBSD did it recently). But I think this is a hack and it's better to revert to another driver. diff of sys/opencrypto/crypto.c between 8-CURRENT http://user.lamaiziere.net/patrick/opencrypto-071208/crypto.c-diff sys/opencrypto/crypto.c http://user.lamaiziere.net/patrick/opencrypto-071208/crypto.c That should not break anything. It would be nice to test it on a box with a Geode LX CPU and a crypto device like a VPN1411 card. I don't have the hardware but I've checked that we revert to the cryptosoft driver when using ipsec and glxsb with AES key's length != 128 bits. Thanks, regards. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
