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 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