A netlink-based user-space crypto API

Posted Oct 22, 2010 1:52 UTC (Fri) by neilbrown (subscriber, #359)
In reply to: A netlink-based user-space crypto API by alonz
Parent article: A netlink-based user-space crypto API

When you say "zero-copy", do you need the transformation to happen in-place, or is it OK to transform (e.g. encrypt) from one buffer to another buffer as long as the app chooses the buffers?

I'm imagining you do an aio_read() to identify the buffer for the transformed data to be written to, then an O_DIRECT write to identify the buffer containing data to be transformed. The underlying implementation would need to notice the presence of a pending aio_read and place the result directly there rather than in the page cache.

I guess the same thing could do an in-place transformation, but it could get messy.

Of course if O_DIRECT wasn't used it would fall back to the simple case of copying to the page cache, transforming, and copying back out.

A netlink-based user-space crypto API

Posted Oct 24, 2010 21:58 UTC (Sun) by alonz (subscriber, #815) [Link] (1 responses)

I refer to "zero-copy" in rather loose terms—not copying more than is necessary. In particular, if the application chooses input/output buffers that are suitable for DMA, I would like to perform a single DMA translation (many cryptography engines have dual-channel DMA engines, so they can read the source buffer via DMA, transform it, and write the output to the target buffer in a single pass).

As for the specific API—all proposals I have seen so far look like hacks, and are rather brittle (e.g. the aio_read solution would require the driver to keep userspace pointers for longer than a single system call, which is generally considered bad taste AFAIK).

A netlink-based user-space crypto API

Posted Oct 24, 2010 23:31 UTC (Sun) by neilbrown (subscriber, #359) [Link]

One man's hack is another man's elegant design :-)

aio, by its very nature, requires the kernel to hold on to user-space pointers for longer than a single system call. This is OK because 'aio_cancel' exists to reclaim the pointer if needed.