Date: Tue, 12 Aug 2008 14:17:08 +0200 From: Pawel Jakub Dawidek <pjd@FreeBSD.org> To: John Baldwin <jhb@freebsd.org> Cc: cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/dev/glxsb glxsb.c glxsb_hash.c Message-ID: <20080812121708.GA2304@garage.freebsd.pl> In-Reply-To: <200808111306.00982.jhb@freebsd.org> References: <200808110841.m7B8fH4m067740@repoman.freebsd.org> <200808111306.00982.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--1yeeQ81UyVL57Vl7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 11, 2008 at 01:06:00PM -0400, John Baldwin wrote: > On Monday 11 August 2008 04:41:08 am Pawel Jakub Dawidek wrote: > > pjd 2008-08-11 08:41:08 UTC > >=20 > > FreeBSD src repository > >=20 > > Modified files: > > sys/dev/glxsb glxsb.c glxsb_hash.c=20 > > Log: > > SVN rev 181593 on 2008-08-11 08:41:08Z by pjd > > =20 > > - Convert sc_sessions_mtx mutex to a rwlock, so in the fast path > > (glxsb_process()) we don't block others when looking for our sessio= n. > > - Simplify the loop responsible for freeing sessions on detach. > > - No need to drop a lock around malloc(M_NOWAIT). > > - Treat ses_used as boolean. > > - Avoid gotos where possible. > > - Various style(9) fixes. > > =20 > > Reviewed by: philip, Patrick Lamaiziere <patfbsd@davenulle.org> >=20 > Would it be worthwhile to abstract the session handling out of padlock(4)= and=20 > glxsb(4)? Are there other CPUs with embedded crypto that will need their= own=20 > drivers that having the abstraction would make writing a driver easier? There is still a lot of work to do. Session handling is probably a good candidate for abstraction, but what I don't like the most is that every single driver have to implement both encryption and hash algorithms to be able to work with IPsec, etc. That's why both padlock and glxsb have software implementation of hash algorithms and lie about supporting them. The opencrypto framework should return a driver that supports both algorithm that consumer is looking for, but if can't find one, it should propose one driver for encryption and another driver for hash calculations and hide this separation from the consumer. The are other issues too. For example some drivers support only one order of operations (encryption and hash) and we have three: Authenticate-then-Encrypt Encrypt-and-Authenticate Encrypt-then-Authenticate The order should be also registered by the driver to the opencrypto framework and if there is no driver with the requested order, opencrypto should handle reordering by itself. Mind you every one of the three most popular crypto protocols (IPsec, SSL, SSH) uses different order of operations. Another issue (pointed out by Patrick) is that glxsb only supports AES with 128 bits key and currently one can only register AES support, which implies all key lengths. BTW. Solution for glxsb for now is probably handling 192 and 256 keys in software and not returing EINVAL. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --1yeeQ81UyVL57Vl7 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFIoX9EForvXbEpPzQRAml6AKDnFPdeOwhzKCocr1lNvMh55b3KaQCg0roQ AOowFCYhoBUJnhDZ/qUEc44= =FZlq -----END PGP SIGNATURE----- --1yeeQ81UyVL57Vl7--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080812121708.GA2304>