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
Quoting Gordan Bobic gordan@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.
On 05/24/2011 08:15 PM, omalleys@msu.edu wrote:
Quoting Gordan Bobic gordan@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
Quoting Gordan Bobic gordan@bobich.net:
On 05/24/2011 08:15 PM, omalleys@msu.edu wrote:
Quoting Gordan Bobic gordan@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... :)
On 05/24/2011 08:54 PM, omalleys@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