Message-ID: <4152.81.207.0.53.1175900790.squirrel@secure.samage.net>
Date:	Sat, 7 Apr 2007 01:06:30 +0200 (CEST)
From:	"Indan Zupancic" <indan@....nu>
To:	"Bill Davidsen" <davidsen@....com>
Cc:	"Tasos Parisinos" <t.parisinos@...ensis.com>,
	"Andi Kleen" <andi@...stfloor.org>, herbert@...dor.apana.org.au,
	linux-kernel@...r.kernel.org, randy.dunlap@...cle.com
Subject: Re: [PATCH resend][CRYPTO]: RSA algorithm patch

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

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


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists