Messages in this thread | | | Date | Fri, 06 Apr 2007 23:53:24 -0400 | From | Bill Davidsen <> | Subject | Re: [PATCH resend][CRYPTO]: RSA algorithm patch |
| |
Indan Zupancic wrote: > On Fri, April 6, 2007 23:30, Bill Davidsen wrote: > >> Tasos Parisinos wrote: >> >>> The main purpose behind the creation of this module was to create the >>> cryptographic infrastructure to develop an in-kernel system of signed >>> modules. >>> >>> > > >>> Although this functionality can be achieved using userland helper >>> programs this may create the need to physically secure entire >>> filesystems which adds to the cost of developing such devices. >>> >> So to save cost on your end you want to make this feature part of the >> mainline kernel. Am I misreading your intent here? >> > > (Tasos was talking about the cost of securing whole file systems versus only > the kernel binary.) > > But if that "entire filesystem" is initramfs, I don't > see any problem. If it fits into the kernel, it also has enough room for an > initramfs with a user space program with the RSA signing. I said this before, > so please look up how initramfs works and tell us why that isn't sufficient > for this case. > > I suspect your answer will be because it isn't the only part and a lot other > infrastructure is need in the kernel to do all the binary signing. But that > code you didn't post, only a MPI module, however nice, which is only a partial > solution to what you want to achieve. Combine that with the kernel policy to > not merge unused code, and you're in the current situation. > > >> Having said all this, we have a boatload of other crypto in the kernel, >> if it's just the crypto module, like aes, anubis or micheal_mic, and is >> GPL compatible, some people may agree. But if this is an embedded >> system, and you have the patch, why not just apply it to your kernel and >> forget mainline? >> > > Currently it's less than a cryptoapi module, as it only provide some functions > to do multi-precision integer calculations, which happen to be the tricky part > of implementing RSA. > > That said, this implementation seems quite good, from a code size and complexity > point of view. So for that alone I think it wouldn't be bad to merge this or a > modified version of this, even if it's unused by the rest of the kernel, it might > be useful for other users. The burden to carry it along for the kernel is quite > small, while the code is worth something and might get improved by their users, > in the end having a central place to collect them. So I think from an open source > ecological point of view, it wouldn't be bad to merge it. > > I see three possible way forwards (alternative is the status quo): > > 1) Move it to user space (into the initramfs embedded into the kernel). > But you'd still need to add binary (modules, libs and programs) load hooks. > > 2) Flesh it out into a ready to use, full blown RSA cryptoAPI module. Whatever > you said earlier, whether you want or not, it's just a block cipher, with the > modulo as block size (I suspect there's some room for code simplification when > assuming fixed block sizes too, by allocating blocksize * 2 space instead of > resizing when needed). > > This would probably be the best solution, to provide most of the hooks while presenting the cryptoAPI for others to use if they wish. Good suggestion. > 3) Go all the way, and post all the other kernel modifications too, to get the > whole binary signing you want to achieve. > Advantage will be that in the end you'll end up with something scrutinized to > death. Disadvantage is that it will be scrutinized to death, as that can take > a lot of time. Maybe you'll end up with a new LSM module, who knows? > > The list is in increasing order of difficulty and quality of your end code. > > It would help if you could find others who also wants something similar and > work together to get it into the kernel. But even if the last step fails, > you still have had people reviewing your code. And failing even that, you at > least shared your code with the rest of the world, which is already something > good (and required by the GPL. But doing it in the open is much more laudable > than hiding it on a website). > > Greetings, > > Indan > > > I think you have covered the possibilities, my read is that your item number two is most likely to be accepted.
-- Bill Davidsen <davidsen@tmr.com> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |