Re: [PATCH 00/19] RFC, v2: "New" /dev/crypto user-space interface

[Miloslav Trmac <mitr@redhat.com>]

----- "Arnd Bergmann" <arnd@arndb.de> wrote:

> On Friday 20 August 2010 10:45:43 Miloslav Trmač wrote:
> > 
> > Major changes since the previous post:
> > * "struct nlattr"-based extensible attributes used for extensibility
> >   of most operations, both for input and output attributes
> 
> The API here looks overly complex resulting from the use of a combination
> of ioctl and netlink. If your interface cannot be easily expressed using
> simple (no indirect pointers or variable-length fields please) ioctl
> and read/write operations, why not go all the way and turn the interface
> into a netlink facility?
I'm afraid the flexibility is necessary: immediately after posting the first interface with fixed structures there were requests for extensions that would be difficult or impossible to implement using the structures; crypto is not something fixed, new algorithms with algorithm-specific parameters appear all the time.  On the positive side, the implementation of session_once as shorthand for session_{init,update,final} is much nicer with the netlink attributes.

Using netlink sockets is impractical: support of zero-copy encryption and auditing requires that operations are performed synchronously in the task context, and the extra overhead of netlink is non-trivial (ioctl() is one syscall per operation, netlink is at least two syscalls per operation); based on a very crude benchmark, this results in about 20% performance penalty when encrypting 256 bytes using cbc(aes) - and that is not counting the impossibility to do zero-copy operations with netlink).  Also matching netlink replies to requests can be complex in a multi-threaded environments if there is one /dev/crypto file descriptor per process.

> >   The libtom* patches will probably still be too large for the mailing list;
> >   the whole patch set is also available at
> >   http://people.redhat.com/mitr/cryptodev-ncr/v2/ .
> 
> They actually seem to have made it to the list. However, the more signficant
> problem is the amount of code added to a security module. 20000 lines of
> code that is essentially a user-level library moved into kernel space
> can open up so many possible holes that you end up with a less secure
> (and slower) setup in the end than just doing everything in user
> space.
Yes, it's a lot of code.   I'm afraid some of the security profiles require public key algorithms, giving some Linux users no choice in the matter.

On the other hand, the user-space crypto API is not inherently tied to the existence of these algorithms; if the public key algorithms were completely unacceptable for some reason, that should still make it possible to add the crypto API as such.

> >   An user-space library is not separated, options are a) root
> >   running daemon that does crypto, but this would be slow due to context
> >   switches, scheduler mismatching and all the IPC overhead and b) use crypto
> >   that is in the kernel.
> 
> I think you will have to back that statement by measurements. There are
> reasonably fast ways to do IPC and the interface you suggest to put in the
> kernel does not exactly look tuned for performance.
See above for the effect of a single additional syscall.  Crypto is often done on small amounts of data at a time (one TLS/SSH record, which can be thousands of bytes in favorable cases, tens of bytes in the worst case), and each context switch is comparatively costly.

> > * FIPS-140-3 calls out for cryptographic functions to be non-debuggable (ptrace)
> >   meaning that you cannot get to the key material. The solution is the same as
> >   above.
> 
> We have kgdb, kdb, qemu gdbserver, tracing and more things that would very
> much make your code debuggable.
The system administrator is usually considered to be excluded from the requirements of such standards.
    Mirek