omalleys@xxxxxxx 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 _______________________________________________ arm mailing list arm@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/arm
