Re: [PATCH v2 01/10] crypto: AF_ALG: add user space interface for AEAD
From: Stephan Mueller
Date: Wed Nov 19 2014 - 01:31:08 EST
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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/