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

[Gordan Bobic]

On 05/24/2011 08:15 PM, omalleys at msu.edu wrote:
> Quoting Gordan Bobic <gordan at bobich.net>:
>
>> On 05/24/2011 07:27 PM, Alexander Boström wrote:
>>> mån 2011-05-23 klockan 15:15 +0100 skrev Gordan Bobic:
>>>
>>>> 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?
>>>
>>> It's probably a lot easier to just patch your kernel build (or ask
>>> whoever builds your kernel to do it). Then you won't need kernel build
>>> tools installed on your little arm device.
>>
>> I really don't think that's a big deal. Cryptodev module takes seconds
>> to build, and even if you are building your own kernel, it means you can
>> just install the new kernel, and the new module with automatically be
>> built for it. So it still saves effort.
>
> I think this is a bigger deal then you assume. I sure as heck don't want
> a compiler sitting on my embedded device facing the outside world

You don't want to be updating the kernel on your embedded device without 
ample preparation either.

> or on my desktop system,

So you don't like having nvidia/ati accelerated graphics with 
manufacturer provided drivers either, then? Or LSI SAS controllers? Or 
anything else that relies on dkms to keep it's drivers up to date.

> just the same as I don't put a compiler on a
> production server system either.

See above. The LSI MPT driver that ships with the kernel on RHEL is 
quite a long way out of date. I guess you could have a build machine 
template for every type system you have, but that's impractical if you 
have a lot of heterogenous hardware.

Besides - I don't see a big deal. If you don't like dkms don't use it - 
build the drivers the hard way. For most people, myself included, it's 
an acceptable solution.

> It is just as easy to compile a rootkit
> as it is a dkms.

If somebody has gained shell access to your box, you've already lost, so 
I don't see this as a particularly viable argument.

> Embedded also has space at a premium and dev tools and
> libraries can eat up space.

If it's embedded, it doesn't get updated often or without good reason, 
and if it really is embedded, then you are probably developing in a 
dedicated environment and planning to deploy on many identical devices. 
In that case you can just push out the driver with the kernel package 
and be done with it. I don't see the two approaches as in any way 
contradictory. The fact that the solution doesn't fit your requirements 
doesn't mean it fits nobody's. I posted the docs on how to do it - 
whether you do it that way or dkms wrapped is entirely up to you. :)

The only point I'm really making is that dkms is a standard, recognized 
way of doing things like this. It may not fit everyone's requirements, 
but it fits a lot of people's requirements. I'd love to see it become a 
non-issue by bundling the driver/headers in the kernel rpms when those 
become available for popular devices, but until then I think dkms would 
make it much easier for most people who don't want to get their hands 
dirty with doing it all manually.

Gordan