Re: RFC: kcrypto - (yet another) user space interface
Sebastian Andrzej Siewior wrote: * Phil Sutter | 2010-06-10 20:22:29 [+0200]: Hello everyone, Hi Phil, please take look at [0] and [1]. From README I can tell that those two posts are different from you have so far. You might want to take a look at AF_PACKET interface. It does zero copy via a ring buffer interface of pre-mmaped user memory. So no get_user_pages() then :) I think that is the way to go. The problem with right or wrong is that they are only known afterwards. For me the right way to go is _to go_. I can see discussions in this least, years ago on talks about the perfect userspace crypto api and rejections implementations because they are not perfect enough. I don't believe there is such thing as a perfect crypto api. Other operating systems have a userspace crypto API (maybe not perfect) but linux hasn't. I don't think this is the way to go. regards, Nikos -- 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
Re: RFC: kcrypto - (yet another) user space interface
* Nikos Mavrogiannopoulos | 2010-06-11 09:47:15 [+0200]: Sebastian Andrzej Siewior wrote: * Phil Sutter | 2010-06-10 20:22:29 [+0200]: The problem with right or wrong is that they are only known afterwards. For me the right way to go is _to go_. I can see discussions in this least, years ago on talks about the perfect userspace crypto api and rejections implementations because they are not perfect enough. I don't believe there is such thing as a perfect crypto api. Other operating systems have a userspace crypto API (maybe not perfect) but linux hasn't. I don't think this is the way to go. Phil asked me for my opinion and he got it. The fundumention problems from what I've seen was the interface: - kernel structs which are exposed to userland which limit the parameters. For instance the iv was limited to 16 bytes while we have allready algos with a much longer iv. - the interface was using write()/poll()/read() and get_user_pages(). I pointed out Herbert's opinion about this and the alternative. So this _was_ allready discsussed. regards, Nikos Sebastian -- 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
Re: RFC: kcrypto - (yet another) user space interface
Hey, Seems like I'm stabbing into open wounds. :) First of all, thanks a lot for your comments. On Fri, Jun 11, 2010 at 11:08:56AM +0200, Sebastian Andrzej Siewior wrote: * Nikos Mavrogiannopoulos | 2010-06-11 09:47:15 [+0200]: Sebastian Andrzej Siewior wrote: * Phil Sutter | 2010-06-10 20:22:29 [+0200]: The problem with right or wrong is that they are only known afterwards. For me the right way to go is _to go_. I can see discussions in this least, years ago on talks about the perfect userspace crypto api and rejections implementations because they are not perfect enough. I don't believe there is such thing as a perfect crypto api. Other operating systems have a userspace crypto API (maybe not perfect) but linux hasn't. I don't think this is the way to go. Phil asked me for my opinion and he got it. The fundumention problems from what I've seen was the interface: - kernel structs which are exposed to userland which limit the parameters. For instance the iv was limited to 16 bytes while we have allready algos with a much longer iv. - the interface was using write()/poll()/read() and get_user_pages(). I pointed out Herbert's opinion about this and the alternative. So this _was_ allready discsussed. For me, this project is a rather pragmatical one - this just needs to get done, and it has to be just perfect enough so my employer finds it usable. Nice to have if I happen to create the perfect CryptoAPI user space interface ever (yeah, right ...) but this is unlikely to happen. For me it's enough to first get the concept right and next make it stable and functional. After that I'm sure we all can tell better if it's worth pushing it towards the kernel or leave it as (yet another) niche product. Greetings, 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
Re: RFC: kcrypto - (yet another) user space interface
Hey Bigeasy, On Thu, Jun 10, 2010 at 11:14:33PM +0200, Sebastian Andrzej Siewior wrote: please take look at [0] and [1]. From README I can tell that those two posts are different from you have so far. Hmm. Indeed, using something like AF_CRYPTO didn't come to my mind so far. Though I'm not sure if this is good or bad - what's the big advantage in introducing an address family for something which doesn't even know addressing as such? No offense here, but all I have is a bunch of bytes which should be transformed by the kernel. Using socket(), connect() and sendmsg() for just that purpose seems a bit too fancy to me. You might want to take a look at AF_PACKET interface. It does zero copy via a ring buffer interface of pre-mmaped user memory. So no get_user_pages() then :) Yes, I've already thought about using just mmap() for the buffer exchange. But what I don't like about it is that the shared buffer is allocated from within the kernel, leading to two preconditions: 1) Unless the user anyway has to fill a locally allocated buffer with the data to transform, at least a single copy is needed to get the data into the kernel buffer. Although get_user_pages() is quite ugly to use, it's flexible enough to take any buffer directly from user space to operate on. (Page alignment constraints, especially with hardware crypto engines, should be another interesting topic in this context.) 2) Space constraints. I can take a hundred 1.5k buffers along with a single, 64M one. Despite that my PoC actually doesn't work with buffers above 64k, using only an in-kernel buffer would make things quite a bit more complicated. I think that is the way to go. [0] http://article.gmane.org/gmane.linux.kernel.cryptoapi/2656 [1] http://article.gmane.org/gmane.linux.kernel.cryptoapi/2658 Reading a bit further from there, splice() is mentioned as another way of exchanging the data buffers. But despite that it's doing about what I've implemented (i.e., using get_user_pages() to fetch the userspace data), there seems to be now sane way back, at least not according to the comments in fs/splice.c. This is actually a limitation of my implementation: all data transformation is done in situ. Fine for stream ciphers, acceptable for block ciphers, but probably FUBAR for hashes, I guess. Greetings, 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
RFC: kcrypto - (yet another) user space interface
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
Re: RFC: kcrypto - (yet another) user space interface
* Phil Sutter | 2010-06-10 20:22:29 [+0200]: Hello everyone, Hi Phil, please take look at [0] and [1]. From README I can tell that those two posts are different from you have so far. You might want to take a look at AF_PACKET interface. It does zero copy via a ring buffer interface of pre-mmaped user memory. So no get_user_pages() then :) I think that is the way to go. [0] http://article.gmane.org/gmane.linux.kernel.cryptoapi/2656 [1] http://article.gmane.org/gmane.linux.kernel.cryptoapi/2658 Phil Sebastian -- 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
