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
Sam Leffler
sam at freebsd.org
Sat Aug 9 22:34:43 UTC 2008
Sam Leffler wrote:
> Poul-Henning Kamp wrote:
>> In message <200808091453.m79ErIuP092318 at 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
More information about the cvs-src
mailing list