----- "Arnd Bergmann" <a...@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
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
