From owner-freebsd-arch@FreeBSD.ORG Wed Feb 4 23:19:20 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C232F16A4CE for ; Wed, 4 Feb 2004 23:19:20 -0800 (PST) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2E99D43D1F for ; Wed, 4 Feb 2004 23:19:19 -0800 (PST) (envelope-from sam@errno.com) Received: from 66.127.85.91 ([66.127.85.91]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.9) with ESMTP id i157JHHQ060655 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 4 Feb 2004 23:19:18 -0800 (PST) (envelope-from sam@errno.com) From: Sam Leffler Organization: Errno Consulting To: Poul-Henning Kamp , arch@freebsd.org Date: Wed, 4 Feb 2004 23:24:18 -0800 User-Agent: KMail/1.5.3 References: <29979.1075898861@critter.freebsd.dk> In-Reply-To: <29979.1075898861@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200402042324.18434.sam@errno.com> Subject: Re: Resolving the crypto duplicity... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2004 07:19:20 -0000 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