From owner-freebsd-arch@FreeBSD.ORG Wed Feb 4 04:47:46 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 333D016A4CE for ; Wed, 4 Feb 2004 04:47:46 -0800 (PST) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id C6C4843D53 for ; Wed, 4 Feb 2004 04:47:43 -0800 (PST) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.10/8.12.10) with ESMTP id i14ClfDF029980 for ; Wed, 4 Feb 2004 13:47:41 +0100 (CET) (envelope-from phk@phk.freebsd.dk) To: arch@freebsd.org From: Poul-Henning Kamp Date: Wed, 04 Feb 2004 13:47:41 +0100 Message-ID: <29979.1075898861@critter.freebsd.dk> Subject: 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: Wed, 04 Feb 2004 12:47:46 -0000 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 ? 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. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.