[fedora-arm] Hardware Crypto Offload on Kirkwood (SheevaPlug)

[Gordan Bobic]

omalleys at msu.edu wrote:

>>>>>> In case anyone is interested, I got this working on F13. It required
>>>>>> building the cryptodev kernel module and rebuilding the standard F13
>>>>>> OpenSSL package with three additional parameters (the cryptodev 
>>>>>> support
>>>>>> is already in the standard OpenSSL package sources, it just isn't
>>>>>> enabled in the default build).
>>>>>>
>>>>>> More details available here:
>>>>>> http://www.altechnative.net/?p=174
>>>>>>
>>>>>> Any chance we can have cryptodev enabled in the standard package 
>>>>>> build?
>>>>>> I cannot see any drawbacks to having it available - when cryptodev
>>>>>> device isn't there, it will simply fall back to the software
>>>>>> implementation. (Note: required cryptodev header file provided by the
>>>>>> external kernel driver).
>>>>>
>>>>> We use upstream Fedora mainline packages. File a bug and once its
>>>>> enabled in Fedora it will come to the ARM platform too.
>>>>
>>>> Filed:
>>>> https://bugzilla.redhat.com/show_bug.cgi?id=706706
>>>
>>> That just rocks, Thanks!!
>>
>> Yeah, it's pretty awesome. It makes the Sheevaplug catch up with the
>> Atom that is 466MHz faster and 4x more power-hungry.
>>
>> What I'm pondering now is something like a dkms package for the
>> cryptodev kernel module, but I seem to remember reading somewhere that
>> dkms is a non-Fedora RHEL thing. What do you guys think would be the
>> best way to approach it, especially since we don't have "standard"
>> kernels at the moment?
>>
> 
> Good question. Although I thought dkms support was recently added like F13.

I thought there was a phylosophical issue with dkms on fedora, because 
it tracks the mainline kernel or something like that.

> My question, is how hard is this to implement the hardware support 
> non-openssl programs.

Not particularly hard if you're writing your own crypto implementation 
anyway, but there's a lot to be said for just linking against OpenSSL. 
It's probably safer to link against the library that has a lot of eyes 
on it than it is to implement your own.

> OpenAFS could use this as it can use a lot of DES 
> encryption, but it uses its own DES implementation. It also happens to 
> be the only one I can think of off the top of my head that uses its own 
> implementation. It would be nice to have.

Is there any technical reason why it couldn't be built against OpenSSL?

This could also be extended to other things, such as md5sum and sha1sum 
from coreutils. They use their own implementation rather than OpenSSL 
(presumably because for something as core as coreutils needs to be 
dependencyless). A couple of thoughts on that subject:

1) Should md5sum, sha1sum and similar be subject to the alternatives 
framework, and be substituted by wrappers that instead call "openssl 
md5" and "openssl sha1" respectively?

2) My testing shows that the coreutils software implementation is 
actually quicker on checksumming large files. Not a lot, mind you, but 
the difference is measurable (1.924s for sha1sum and 1.998s for openssl 
sha1 for a kernel tar.bz2 ball, for the best of three runs of each). But 
the sys+user time for sha1sum adds up to the wallclock total, whereas 
for the cryptodev accelerated openssl run, the sys+user is 0.620s, i.e. 
less than a third of wallclock.

This might actually be a debate worth having on the primary arch list 
(Note: I'm not subscribed to that one.) since most of the current 
generation x86 processors from Intel, AMD and Via have similar crypto 
offload features at least for AES.

Gordan