From owner-cvs-src@FreeBSD.ORG Sat Aug 9 22:34:43 2008 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5D4751065672; Sat, 9 Aug 2008 22:34:43 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 261F88FC0C; Sat, 9 Aug 2008 22:34:43 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id m79MYem4087959 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 9 Aug 2008 15:34:41 -0700 (PDT) (envelope-from sam@freebsd.org) Message-ID: <489E1B80.8090807@freebsd.org> Date: Sat, 09 Aug 2008 15:34:40 -0700 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.9 (X11/20071125) MIME-Version: 1.0 To: Poul-Henning Kamp References: <97980.1218298242@critter.freebsd.dk> <489DDD16.7000907@freebsd.org> In-Reply-To: <489DDD16.7000907@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC--Metrics: ebb.errno.com; whitelist Cc: cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org, Philip Paeps Subject: Re: cvs commit: src/sys/conf files.i386 src/sys/dev/glxsb glxsb.c glxsb.h glxsb_hash.c src/sys/i386/conf NOTES src/sys/modules Makefile src/sys/modules/glxsb Makefile X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Aug 2008 22:34:43 -0000 Sam Leffler wrote: > Poul-Henning Kamp wrote: >> In message <200808091453.m79ErIuP092318@repoman.freebsd.org>, Philip >> Paeps writ >> es: >> >>> philip 2008-08-09 14:52:31 UTC >>> >>> >> >> >>> Add glxsb(4) driver for the Security Block in AMD Geode LX >>> processors (as >>> found in Soekris hardware, for instance). The hardware supports >>> acceleration >>> of AES-128-CBC accessible through crypto(4) and supplies entropy to >>> random(4). >>> >>> TODO: >>> >>> o Implement rndtest(4) support >>> >> >> Just for the record: I think it is important that we have a >> test-program >> that checks that these hardware assisted crypto algorithms actually >> do the right thing. >> >> I would really hate if people found out that they had been using >> the ROT52 algorithm due to some silly bug we don't notice along the >> way. >> >> It doesn't have to be very advanced, just run a couple of the standard >> test-vectors to see that the result is correct. >> >> > tools/tools/crypto/cryptotest is kinda setup to do that. No test > vectors though. I just remembered that for the net80211 crypto support I did test vectors in loadable modules (tools/tools/regression/net80211). This was required because the crypto support isn't exposed to user space and things are tied to 802.11 packet formats. The opencrypto support is exposed to user space through /dev/crypto so perhaps not relevant unless someone wanted to test paths accessible only in the kernel. Sam