Date: Wed, 10 Dec 2008 23:34:40 +0100 From: Patrick =?ISO-8859-15?Q?Lamaizi=E8re?= <patfbsd@davenulle.org> To: Philip Paeps <philip@freebsd.org> Cc: freebsd-hackers@freebsd.org Subject: Re: crypto(9) choose another driver if we cannot open a session on it Message-ID: <20081210233440.41bd1c47@baby-jane> In-Reply-To: <20081208202155.GA7403@detritus.paeps.cx> References: <20081207224551.13ca3590@baby-jane> <20081208202155.GA7403@detritus.paeps.cx>
next in thread | previous in thread | raw e-mail | index | archive | help
Le Mon, 8 Dec 2008 21:21:55 +0100, Philip Paeps <philip@freebsd.org> a écrit : Hello, > On 2008-12-07 22:45:51 (+0100), Patrick Lamaizière > <patfbsd@davenulle.org> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20081210233440.41bd1c47>