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

[omalleys at msu.edu]

Quoting Gordan Bobic <gordan at bobich.net>:

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

Well depends on how you look at it. It can be a valuable learning  
experience  trying to figure out how exactly to recover from your  
mistake.

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

I have to recompile them for various kernels. I have the same issue  
with OpenAFS if the package hasn't been updated yet and a new kernel  
is released.

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

I do have a build environment for a number of different services.
I moved most of the dev environments to virtual machines though.

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

Yes but they may have shell access and build the kit to gain root access.

>> 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. :)

I think the docs were actually well written. I quite enjoyed reading them.

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

I understand your argument. It seems strange that you would be making  
the argument given you are one of the people who likes to get their  
hands dirty. :)

I just think there has to be a better way to do it, sans moving to a  
bsd style kernel... :)