Am Mittwoch, 19. November 2014, 12:27:04 schrieb Herbert Xu: Hi Herbert, > On Wed, Nov 19, 2014 at 05:20:42AM +0100, Stephan Mueller wrote: > > When looking deeper into skcipher_sendmsg, I see that the input data is > > copied into the kernel using memcpy_fromiovec. The memory is allocated > > before the memcpy call by skcipher_alloc_sgl. > > Zero-copy is done through sendpage. I am slightly at a loss here -- if you could give me a hint on how you think it can be implemented, I would be grateful. Let us assume the AD || plaintext buffer is known to the kernel, either through sendpage or sendmsg. The entire buffer is split into chunks of scatterlists with ctx->tsgl. After processing one scatterlist from ctx->tsgl, that scatterlist is released via skcipher_pull_sgl. Now, for AD, we need to consider: - AD can span multiple ctx->tsgl chunks - these AD scatterlist chunks cannot be released after a normal encryption operation. The associated data must be available for multiple operations. So, while plaintext data is still flowing in, we need to keep operating with the same AD. Thus I am wondering how the rather static nature of the AD can fit with the dynamic nature of the plaintext given the current implementation on how plaintext is handled in the kernel. To me, AD in league with an IV considering its rather static nature. Having said that, the IV is also not transported via the plaintext interface, but via a setsockopt. Shouldn't the AD be handled the same way? > > Cheers, -- Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
