On 11/2/2017 10:14 AM, Gilad Ben-Yossef wrote: > We are being passed an IV buffer from unknown origin, which may be > stack allocated and thus not safe for DMA. Allocate a DMA safe > buffer for the IV and use that instead. > IIUC this fixes only the (a)blkcipher / skcipher algorithms. What about aead, authenc? The fact that only the skcipher tcrypt tests use IVs on stack doesn't mean aead, authenc implementations are safe - other crypto API users could provide IVs laying in non-DMAable memory. To reiterate, the proper approach is to fix the crypto API to guarantee IVs are DMAable. However Herbert suggests he is not willing to do this work: https://www.mail-archive.com/linux-crypto@xxxxxxxxxxxxxxx/msg28821.html A few high-level details mentioning what this implies would be helpful, in case somebody else decides its worth pursuing this path. The compromise is to fix all crypto drivers that need DMAable IVs. IMHO this is suboptimal, both in terms of performance (memory allocation, memcpy) and increased code complexity. Horia _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
