Date: Wed, 4 Feb 2004 23:24:18 -0800 From: Sam Leffler <sam@errno.com> To: Poul-Henning Kamp <phk@phk.freebsd.dk>, arch@freebsd.org Subject: Re: Resolving the crypto duplicity... Message-ID: <200402042324.18434.sam@errno.com> In-Reply-To: <29979.1075898861@critter.freebsd.dk> References: <29979.1075898861@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday 04 February 2004 04:47 am, Poul-Henning Kamp wrote: > I'm just using Rijndael/AES for illustration, the same issues apply > to various other algorithms. > > Right now we have identical (apart from some trivial details) of the > AES algorithms in the kernel: > > [1] src/sys/crypto/rijndael/* > [ipsec, random and geom_bde options] > > [2] arc/sys/opencrypto/rijndael.? > [crypto] > > As far as I can see, the src/crypto stuff which is slightly better > organized, originally arrived with KAME, and the sys/opencrypto > stuff of came in with sam@'s HW-crypto support work. > > The HW-crypto support code only needs a software implementation as > a fall-back if hardware does not offer it. > > I would like to propose that we try to eliminate the private copies > of crypto functions in sys/opencrypto and instead focus on the > copies in src/crypto as our "generic" implementations. > > Are there any technical or political reasons why we should not do this ? > All the cipher code in opencrypto is there for a reason; either because it ran substantially faster than the KAME code at the time I imported the crypto framework or because there were API incompatbilities that made using the KAME versions difficult. In general the one overriding rule I had was that I could not remove any code in crypto so anything new had to go in opencrypto. Where there are no longer reasons to keep duplicate copies I'm fine with removing code from opencrypto. But before you do this you might also compare the code to the current work in openbsd (from which this stuff came) to see if there are changes there that might change your decision. > > Next problem is that there currently is no way to detect if opencrypto > is present in the kernel or not, or for that matter if we have the > rijndael code in there or not. This makes life for GBDE as a KLD > sort of interesting. > > Were are we going with our kernel modularization ? > > Do we want to use multi-level module dependencies ? > > "gbde depends on opencrypto _or_ rijndael" > "opencrypto depends on rijndael and [...]" > "random depends on rijndael" > > If not, how else do we want to manage this "creepy maze of dependencies, > all tangled" ? > > For reference: > a rijndael implementation is about 14kB in .o files > > GBDE is about 15kB in .o files > > Opencrypto framework is about 25kB in .o files > Sw-crypto engines an additional 40kB (incl rijndael) > > One obvious and tempting solution is to make opencrypt non-optional > since that solves all the dependency issues. I tried to get opencrypto included in GENERIC for 5.2 but was too late. I think making it part of the base system is too costly for embedded environments but could be persuaded otherwise. I think with your recent mods that gbde depends on opencrypto so I'm not sure why you're worried about an explicit rijndael dependency unless you can build gbde w/ and w/o the opencrypto usage. Sam
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200402042324.18434.sam>