1:44 p.m.
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.
Anyway, you'll also need support in various libraries and
applications,
which means that cryptodev.h must be available somewhere. The right
place to put that is probably glibc-devel or kernel-headers, but that's
not likely to happen until the support is in the mainline kernel.
I was thinking about including it in the dkms-cryptodev package. After
all, it is cryptodev module that brings it along.
I suggest you try to help get cryptodev upstreamed into kernel.org
or
figure out why that hasn't happened. Once there's a solution in place
upstream it's a lot easier to let the code trickle down naturally into
all kernels and get support added to various related components.
My experience on the lkml has been that it's pretty difficult to not get
ignored. Perhaps somebody better established there might stand a better
chance.
Gordan
2:15 p.m.
New subject: Hardware Crypto Offload on Kirkwood (SheevaPlug)
Quoting Gordan Bobic <gordan(a)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
or on my desktop system, just the same as I don't put a compiler on a
production server system either. It is just as easy to compile a
rootkit as it is a dkms. Embedded also has space at a premium and dev
tools and libraries can eat up space.
2:28 p.m.
New subject: Hardware Crypto Offload on Kirkwood (SheevaPlug)
On 05/24/2011 08:15 PM, omalleys(a)msu.edu wrote:
Quoting Gordan Bobic <gordan(a)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
2:54 p.m.
New subject: Hardware Crypto Offload on Kirkwood (SheevaPlug)
Quoting Gordan Bobic <gordan(a)bobich.net>:
On 05/24/2011 08:15 PM, omalleys(a)msu.edu wrote:
> Quoting Gordan Bobic <gordan(a)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... :)
3:05 p.m.
New subject: Hardware Crypto Offload on Kirkwood (SheevaPlug)
On 05/24/2011 08:54 PM, omalleys(a)msu.edu wrote:
> 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.
As opposed to using wget, curl, or even the magic /dev/tcp from shell to
download it pre-cooked? Sorry, I just don't see it making a difference.
>> 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.
By all means, feel free to paste/link on the official wiki. :)
> 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 _don't mind_ getting my hands dirty _when I have to_, but I do like to
come up with a solution that I have to implement once, and from there on
it takes care of itself.
I just think there has to be a better way to do it, sans moving to a
bsd
style kernel... :)
Feel free to chase cryptodev inclusion in mainline - I'm totally for
that, I just think it'll take years and I am simply not prepared to wait
for it. There is also an argument that we should perhaps involve the
developer of the module in this conversation, too, and see what they
think. :)
Gordan
4723
days inactive
4723
days old
4 comments
2 participants
participants (2)
-
Gordan Bobic -
omalleys＠msu.edu