Date: Fri, 12 Dec 2008 23:57:35 +0100 From: Patrick =?ISO-8859-15?Q?Lamaizi=E8re?= <patfbsd@davenulle.org> To: Sam Leffler <sam@freebsd.org> Cc: freebsd-hackers@freebsd.org Subject: Re: crypto(9) choose another driver if we cannot open a session on it Message-ID: <20081212235735.7deaea52@baby-jane> In-Reply-To: <494047CB.6050400@freebsd.org> References: <20081207224551.13ca3590@baby-jane> <20081208202155.GA7403@detritus.paeps.cx> <20081210233440.41bd1c47@baby-jane> <494047CB.6050400@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Le Wed, 10 Dec 2008 14:50:51 -0800, Sam Leffler <sam@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20081212235735.7deaea52>