Am Freitag, 13. Januar 2017, 00:06:29 CET schrieb Herbert Xu: Hi Herbert, > On Thu, Jan 12, 2017 at 05:01:13PM +0100, Stephan Müller wrote: > > I fully agree. Therefore, I was under the impression that disregarding the > > AAD in recvmsg entirely would be most appropriate as offered with the > > patch "crypto: AF_ALG - disregard AAD buffer space for output". In this > > case we would be fully POSIX compliant, the kernel would not copy the AAD > > (and thus perform multiple memcpy operations due to copy_from_user and > > copy_to_user round trips) and leave the AAD copy operation entirely to > > user space. > Yes but then you'd have to play nasty games to fit this through > the kernel API. I would not understand that statement. With the patch mentioned above that I provided some weeks ago, we have the following scenario for an encryption (in case of decryption, it is almost identical, just the tag location is reversed): user calls sendmsg with data buffer/IOVEC: AAD || PT -> algif_aead turns this into the src SGL user calls recvmsg with data buffer/IOVEC: CT || Tag -> algif_aead creates the first SG entry in the dst SGL pointing to the AAD from the src SGL -> algif_aead appends the user buffers to the dst SGL -> algif_aead performs its operation and during that operation, only the CT and Tag parts are changed I.e. with the pre-pending of the SG pointing to the AAD from the src SGL to the dst SGL we have a clean invocation of the kernel API. Yet, we avoid copy round trips of the AAD from src to dst in the kernel. > Besides, we could still do in-place crypto even > though you suggested that it's complicated. Is that crypto-in-place operation really a goal we want to achieve if we "buy" it with a memcpy of the data from the src SGL to the dst SGL before the crypto operation? Can we really call such implementation a crypto-in-place operation? > It's not really. I concur, for encryption the suggested memcpy is not difficult. Only for decryption, the memcpy is more challenging. > All we have to do is walk through the SG list and compare each > page/offset. For the common case it's going to be a single-entry > list. > > 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
