|
|
Subscribe / Log in / New account

A netlink-based user-space crypto API

A netlink-based user-space crypto API

Posted Oct 21, 2010 20:54 UTC (Thu) by alonz (subscriber, #815)
Parent article: A netlink-based user-space crypto API

Well, speaking as the architect of a hardware cryptography device…

I also dislike for Xu's proposal. Sorry.

My issues with this API (unlike the previous commenters) relate to function, not form:

  1. It creates unnatural semantic linkages between sockets (most importantly these pairs of sockets used for AEAD, which need to be written to/read from in a very particular ordering)
  2. There is no way to achieve zero-copy cipher operation with this API (at least one of the sendmsg()/recv() will have to copy data to/from an skbuff).
I don't really have a good alternative API; crypto just doesn't appear to map cleanly to the Unix abstractions. Maybe a specialized system call ("sendrecvmsg()"/"servercall()" or somesuch) could help with the second point.


to post comments

A netlink-based user-space crypto API

Posted Oct 22, 2010 0:59 UTC (Fri) by SEJeff (guest, #51588) [Link] (2 responses)

Just curious, what hardware crypto device? Can you disclose that and is any information public?

A netlink-based user-space crypto API

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

I'm the lead architect for Discretix' CryptoCell embedded security platform (which is also the basis for the Intel Moorestown security subsystem).

A netlink-based user-space crypto API

Posted Oct 25, 2010 12:13 UTC (Mon) by SEJeff (guest, #51588) [Link]

Ah thanks. That gives much better context.

A netlink-based user-space crypto API

Posted Oct 22, 2010 1:52 UTC (Fri) by neilbrown (subscriber, #359) [Link] (2 responses)

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.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds