lkml.org 
[lkml]   [2007]   [Mar]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH 1/5] AF_RXRPC: Add blkcipher accessors for using kernel data directly [try #2]
Date
Christoph Hellwig <hch@infradead.org> wrote:

> I don't quite understand all these indirections. What's the problem
> with just having a helper that builds the scatterlist for you?

I was trying to avoid building a scatterlist completely. There's not much
point because the scatterlist approach involves finding out the page struct and
then kmapping it just so that the FCrypt algorithm can read 8 or 16 bytes of
data from kernel space. Why do that if we can avoid it? It's a waste of
processing time, and has to be done on every secure packet.

> We allow dma access to arbitary pieces of _dynamically_ allocated kernel
> memory, and I think using the crypto subsystem on the stack is not allowed
> at all.

FCrypt is only available in software as far as I know. For producing and
checking packet signatures, using hardware support would be a waste of time as
the size of the crunched data is so small (a single 8-byte fragment per
packet).

> But the even bigger question is, how does this relate to rxrpc?

RxRPC has security features, up to and including full packet content encryption
if you select it.

> very odd line split

It's not really odd. The "static" and "inline" don't actually add anything to
the function template. They're merely scope limiters / optimisation
controllers, and so make a lot of sense placed on their own line.

David
-
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/

\
 
 \ /
  Last update: 2007-03-16 15:01    [W:0.137 / U:0.016 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site