Re: Crypto Update for 2.6.38

[Linus Torvalds]

On Thu, Jan 6, 2011 at 1:39 PM, Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxxx> wrote:
> On Thu, Jan 06, 2011 at 01:23:19PM -0800, Linus Torvalds wrote:
>>
>> Explanations of interface. Code. Who uses it? What are the actual
>> performance benefits on real code?
>
> You snipped out the bit in my reply where I expanded on it:

You didn't expand on it AT ALL.

You just mentioned "the interface". I haven't seen WHAT THAT INTERFACE IS!

How hard is that to understand?

> Here is the original cover email for the patches:

Ok, this is more like it. This is roughly what I wanted to see:

> : Here is a sample hash program (note that these only illustrate
> : what the interface looks like and are not meant to be good examples
> : of coding :)

But I'm still missing the part where you show that there is any actual
use case that makes sense, and that actually improves performance.
Maybe it's been posted somewhere else, but the thing is, you're asking
_me_ to pull, and as a result you need to convince _me_ that this is a
good idea. So if it's been posted/discussed extensively elsewhere,
please point to those discussions.

I really don't like adding interfaces that don't have hard uses
associated with them. We've done it in the past, and it tends to be a
morass and a bad idea. That's been true even when the idea has been my
own, and thus obviously genius-level and clearly the RightThing(tm),
like "splice()". And it's why I push back on new interfaces when I see
them.

Btw, it doesn't have to be about performance per se. Does this allow
people to use keys without actually _seeing_ those keys? Your example
implies that that is not the case, but that's actually one of the few
reasons to actually support a kernel crypto interface - the ability to
have private personal keys around, but not having to actually let
possibly untrusted programs see them.

For example of why something like that matters, I can well see myself
using some program to encrypt things. But maybe I don't trust that
program enough to give it my actual private keys. In that case, kernel
support is a real feature.

But in your example, it looks like you just give it the key. Which to
me means that you're totally missing one of the major reasons for
having a separate protection domain.

And that makes me think that the interface is bad. And that's why it's
a big change to go from "internal kernel crypto interface" to "actual
user-space interface to the kernel crypto engine". The first one can
be fixed. The second one cannot.

So I'm not necessarily hung up on "performance", but I am hung up on
"there needs to be a point", and "the interface needs to be
-correct-". Performance would be one such point. Not just 'the
hardware is there'. I know the hardware exists, but I'm not at all
convinced that DMA with all the cacheflushing will ever actully be
faster the the CPU. And if it can, I want to hear about the real-world
situation where it actually is used.

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