Linux Kernel(Android) 加密算法总结（二）- A netlink-based user-space crypto API

User-space access to the kernel cryptography subsystem has reared its headseveral times of late. We lookedat one proposal back in August that had a /dev/cryptointerface patterned after similar functionality in OpenBSD. There is another related effort, known as the NCR API, andcrypto API maintainer Herbert Xu has recently posted an RFC for yet another. But giving user space the ability to request that the kernelperform its computation-intensive crypto operations is not uncontroversial.

As noted back in August, some kernel hackers are skeptical that there wouldbe any performance gains by moving user-space crypto into the kernel. Butthere are a number of systems, especially embedded systems, with dedicatedcryptographic hardware. Allowing user space to access that hardware willlikely result in performance gains, in fact 50-100x performance improvementshave been reported.

Another problem with both the /dev/crypto and NCR APIs(collectively known as the cryptodev-linux modules) is theaddition of an enormous amount of code to the kernel to supportcrypto algorithms beyond those that are already available. Those twomodules have adapted user-spacelibraries for crypto and multi-precision integers and included them intothe kernel. They are necessary to support some government crypto standards and certifications that require aseparation between user space and crypto processing. So, the cryptodev-linux modules are trying tosolve two separate (or potentially separate) problems: user-space access tocrypto hardware acceleration and security standards compliance.

When Xu first put out an RFC on his ideafor the API (without any accompanying code) back in September, ChristophHellwig had a rather strongly wordedreaction:

doing crypto in kernel for userspace consumers [is] simply insane.It's computational intensive code which has no business in kernel spaceunless absolutely required (e.g. for kernel consumers). In additionto that adding the context switch overhead and address space transitionsis god [awful] too.

Xu more or less agrees with Hellwig, but sees his API as a way to provideaccess to the hardware crypto devices. Because Xu's API is based onnetlink sockets (as opposed to ioctl()-based or a brand new API that thecryptodev-linux modules introduce), he is clearly hoping that it will provide a way forward without requiring such large changes to the kernel:

FWIW I don't care about user-space using kernel software crypto atall. It's the security people that do.

The purpose of the user-space API is to export the hardware cryptodevices to user-space. This means PCI devices mostly, as thingslike aesni-intel [Intel AES instructions] can already be used withoutkernel help.

Now as a side-effect if this means that we can shut the securitypeople up about adding another interface then all the better. ButI will certainly not go out of the way to add more crap to thekernel for that purpose.

The netlink-based interface uses a new AF_ALG address family that gets passed to the initialsocket() call. There is also a new struct sockaddr_algthat contains information about what type of algorithm (e.g. "hash" or "skcipher") is tobe used as well as the specific algorithm name (e.g. "sha1" or "cbc(aes)")that is being requested. That structure is then passed in thebind() call onthe socket.

For things like hashing, where there is little or no additional informationneeded, an accept() is done on the socket, which yields anoperation file descriptor. The data to be hashed is written to that descriptorand, when there is no more data to be hashed, the appropriate number ofbytes (20 for sha1) are then read from the descriptor.

It is a bit morecomplicated for ciphers.Before accepting the connection on the socket, a key needs to beestablished for a symmetric key cipher. That is done with asetsockopt() call using the new SOL_ALG level andALG_SET_KEY option name and passing the key data and itslength. But there are additional parameters that need to be set up forciphers, and those are done using sendmsg().

A cipher will need to