>>>>> 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
>>>>> is already in the standard OpenSSL package sources, it just
>>>>> enabled in the default build).
>>>>> More details available here:
>>>>> Any chance we can have cryptodev enabled in the standard package
>>>>> 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
>>>>> 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.
>> 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
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.