linux-kernel - Re: [PATCH 1/5] AF_RXRPC: Add blkcipher accessors for using kernel data directly [try #2]

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <25094.1174053465@redhat.com>
Date:	Fri, 16 Mar 2007 13:57:45 +0000
From:	David Howells <dhowells@...hat.com>
To:	Christoph Hellwig <hch@...radead.org>
Cc:	davem@...emloft.net, netdev@...r.kernel.org, herbert.xu@...hat.com,
	linux-kernel@...r.kernel.org, arjan@...radead.org
Subject: Re: [PATCH 1/5] AF_RXRPC: Add blkcipher accessors for using kernel data directly [try #2] 

Christoph Hellwig <hch@...radead.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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/