Hi Phil,

Note on  implementation: I see that you're using the synchronous (blkcipher) 
interface and not the async (ablkcipher) one. I'm not 100% sure about this, but 
it appears to me that you can't utilize async HW drivers this way (there's 
adapter code from async client to sync driver but not the other way around).

With regards to interface, I don't know enough to comment about the proposed 
alternatives, but the use of write() and read() appears problematic - it looks 
inconsistent with the semantics of write() in that the user must not modify the 
buffer after write() - it looks like aio semantics but without the aio 
interface.

With regards to mmap preventing zero copy - In many cases you can assemble the 
things you want to crypt in the mmap buffer upfront. Still in other cases you 
need to copy the data at least once anyway, so you might as well start off by 
copying to the mmap area. Taking TLS as an example - you have to build a TLS 
record before you can encrypt/hash it. The header is poorly aligned and there's 
the padding at the end - there seems to be no escaping copying it once inside 
the TLS library. You may place your record buffers in the mmap area. So I guess 
what I'm saying is that the mmap approach doesn't break interface semantics, 
and in most important cases can be used to provide a solution that's as good as 
the zero-copy one.

Just my 2c,
Uri

On 6/10/2010 9:22 PM, Phil Sutter wrote:
> Hello everyone,
> 
> my employer wants to have a lightweight, zero-copy user space interface
> to the Crypto-API and I *think* I'm on the right way to realising this.
> 
> What I've got so far is just a proof-of-concept, tested only with
> cbc(aes), merely as generic as I'd like it to be, but with zero-copy of
> the actual data buffers (which reside in user space) and asynchronous
> operation.
> 
> You can check it out via git://nwl.cc/~n0-1/kcrypto.git or simply have a
> look at http://nwl.cc/cgi-bin/git/gitweb.cgi?p=kcrypto.git;a=summary. If
> you do so, you may in return flame me as much as you like to. :)
> 
> I know that it's far from being ready for use as the sole crypto API
> user space interface, but I'm convinced as well that it will never be
> unless someone with Crypto-API skills points out at least the very basic
> design flaws I've already created.
> 
> As this is not yet being used in production (of course), I'm totally
> open to changes. So taking this as start of a collaborative project
> would be perfect for me, too.
> 
> Greetings (and sorry for yet another interface approach),
> Phil
> --
> To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to