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

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

[Miloslav Trmac]

----- "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

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

[Miloslav Trmač]

Hello,
following is a patchset providing an user-space interface to the kernel crypto
API.  It is based on the older, BSD-compatible, implementation, but the
user-space interface is different.

Major changes since the previous post:
* "struct nlattr"-based extensible attributes used for extensibility
  of most operations, both for input and output attributes
* algorithms (ciphers, key wrapping, key derivation) are identified using
  strings in the userspace API
* Full compat_ioctl implementation
* Version number added to the data format used when wrapping keys for storage
* Patch set split into smaller parts, reordered to keep the tree buildable.
  (If you want to review primarily the user-space API, see patches
  1,14,15,17,18.)

  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/ .

Original patch set description follows.

These are the major differences compared to the BSD-like interface:

* The API supports key storage and management inside the kernel.
  An application can thus ask the kernel to generate a key; the key is
  then referenced via an integer identifier, and the application can be
  prevented from accessing the raw key data.  Such a key can, if so configured,
  still be wrapped for key transport to the recipient of the message, and
  unwrapped by the recipient.

  The kernel key storage does not span system reboots, but applications can
  also wrap the keys for persistent storage, receiving an encrypted blob that
  does not reveal the raw key data, but can be later loaded back into the
  kernel.

* More algorithms and mechanisms are supported by the API, including public key
  algorithms (RSA/DSA encryption and signing, D-H key derivation, key wrapping).

Motivations for the extensions: governments are asking for more security
features in the operating systems they procure, which make user-space
implementations impractical.  A few examples:

* Advanced crypto module for OSPP for Common Criteria requires OS services
  implementing several low-level crypto algorithms (e.g. AES, RSA).  This
  requires the separation of crypto services from the consumer of those
  services. (The threat model is that apps tend to have more vulnerabilities
  than libraries and compromise of the app will lead to the ability to access
  key material.) 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.

* 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.

* GPOSPP requires auditing for crypto events (so does FIPS-140 level 2 cert).
  To do this you need any crypto to have CAP_AUDIT_WRITE permissions which
  means making everything that links to openssl, libgcrypt, or nss setuid
  root. Making firefox and 400 other applications setuid root is a non-starter.
  So, the solution is again to use crypto in the kernel where auditing needs no
  special permissions.

Other advantages to having kernel crypto available to user space:

* User space will be able to take advantage of kernel drivers for hardware
  crypto accelerators.

* glibc, which in some configurations links to libfreebl3.so for hashes
  necessary for crypt(), will be able to use the kernel implementation; this
  means one less library to load and dynamically link for each such process.

The code is derived from the original cryptodev-linux patch set; most of the
new implementation was written by Nikos Mavrogiannopoulos
<n.mavrogiannopoulos@gmail.com>.  Attributions are included in the respective
source files.

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

[Ted Ts'o]

On Fri, Aug 20, 2010 at 10:45:43AM +0200, Miloslav Trmač wrote:
> Hello, following is a patchset providing an user-space interface to
> the kernel crypto API.  It is based on the older, BSD-compatible,
> implementation, but the user-space interface is different.

What's the goal of exporting the kernel crypto routines to userspace,
as opposed to just simply doing the crypto in userspace?  Is it to
access hardware crypto accelerators?  (1) I wasn't aware the kernel
crypto routines actually used crypto accelerators, and (2) more often
than not, by the time you take into account the time to move the
crypto context as well as the data into kernel space and back out, and
after you take into account price/performance, most hardware crypto
accellerators have marginal performance benefits; in fact, more often
than not, it's a lose.

If the goal is access to hardware-escrowed keys, don't we have the TPM
interface for that already?

So I'm bit at a list what's the whole point of this patch series.
Could you explain that in the documentation, please?  Especially for
crypto, explaining when something should be used, what the threat
model is, etc., is often very important.

Thanks, regards,

						- Ted

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

[Nikos Mavrogiannopoulos]

On 08/20/2010 03:56 PM, Ted Ts'o wrote:
> On Fri, Aug 20, 2010 at 10:45:43AM +0200, Miloslav Trmač wrote:
>> Hello, following is a patchset providing an user-space interface to
>> the kernel crypto API.  It is based on the older, BSD-compatible,
>> implementation, but the user-space interface is different.
> 
> What's the goal of exporting the kernel crypto routines to userspace,
> as opposed to just simply doing the crypto in userspace? 

This was the goal of the original cryptodev OpenBSD API and the
subsequent linux port in http://home.gna.org/cryptodev-linux/. In
typical PCs it might even be slower to use such an accelerator in kernel
space, but in embedded systems where the hardware version of AES might
be 100 times faster than the software it might make sense.

However the design goal of this API is to separate cryptographic
operations from the applications. That is applications in userspace can
use keys, but the keys cannot be extracted from them, so for example
code injection in the web server will not be able to extract the private
key of the web service. (this approach is also required for
certification of linux on certain fields as Miloslav described in the
first post).

The interface is designed in a way that it can be wrapped by a PKCS #11
module and used transparently by other crypto libraries
(openssl/nss/gnutls). TPM is quite limited in this respect and cannot
fulfill this goal.

> So I'm bit at a list what's the whole point of this patch series.
> Could you explain that in the documentation, please?  Especially for
> crypto, explaining when something should be used, what the threat
> model is, etc., is often very important.

A detailed document describing this framework, threats and model is on
its way.


best regards,
Nikos

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

[Ted Ts'o]

On Fri, Aug 20, 2010 at 07:03:18PM +0200, Nikos Mavrogiannopoulos wrote:
> On 08/20/2010 03:56 PM, Ted Ts'o wrote:
> > On Fri, Aug 20, 2010 at 10:45:43AM +0200, Miloslav Trmač wrote:
> >> Hello, following is a patchset providing an user-space interface to
> >> the kernel crypto API.  It is based on the older, BSD-compatible,
> >> implementation, but the user-space interface is different.
> > 
> > What's the goal of exporting the kernel crypto routines to userspace,
> > as opposed to just simply doing the crypto in userspace? 
> 
> This was the goal of the original cryptodev OpenBSD API and the
> subsequent linux port in http://home.gna.org/cryptodev-linux/. In
> typical PCs it might even be slower to use such an accelerator in kernel
> space, but in embedded systems where the hardware version of AES might
> be 100 times faster than the software it might make sense.

OK, but I hope that in that case, we don't go encouraging applications
to use the /dev/crypto API directly.  I know a number of distributions
have been standardizing on NSS as the library that all of their
applications will use, such that by simply configuring libnss
differently, the crypto can either be done in userspace, or it can be
done in hardware, either for crypto acceleration purposes or for when
the key is locked inside hardware can only be used with appropriate
authentication to encrypt or sign data passed to the hardware device.

If you encourage applications to use /dev/crypto directly, then either
(a) they will be much slower on PC's, or (b) the applications will
need to be rewritten when they are moved between your embedded devices
and standard PC's.

					- Ted

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

[Tomas Mraz]

On Fri, 2010-08-20 at 19:48 -0400, Ted Ts'o wrote: 
> On Fri, Aug 20, 2010 at 07:03:18PM +0200, Nikos Mavrogiannopoulos wrote:
> > On 08/20/2010 03:56 PM, Ted Ts'o wrote:
> > > On Fri, Aug 20, 2010 at 10:45:43AM +0200, Miloslav Trmač wrote:
> > >> Hello, following is a patchset providing an user-space interface to
> > >> the kernel crypto API.  It is based on the older, BSD-compatible,
> > >> implementation, but the user-space interface is different.
> > > 
> > > What's the goal of exporting the kernel crypto routines to userspace,
> > > as opposed to just simply doing the crypto in userspace? 
> > 
> > This was the goal of the original cryptodev OpenBSD API and the
> > subsequent linux port in http://home.gna.org/cryptodev-linux/. In
> > typical PCs it might even be slower to use such an accelerator in kernel
> > space, but in embedded systems where the hardware version of AES might
> > be 100 times faster than the software it might make sense.
> 
> OK, but I hope that in that case, we don't go encouraging applications
> to use the /dev/crypto API directly.  I know a number of distributions
> have been standardizing on NSS as the library that all of their
> applications will use, such that by simply configuring libnss
> differently, the crypto can either be done in userspace, or it can be
> done in hardware, either for crypto acceleration purposes or for when
> the key is locked inside hardware can only be used with appropriate
> authentication to encrypt or sign data passed to the hardware device.

Yes, this exactly is the plan. All the major crypto libraries - NSS,
OpenSSL, libgcrypt - are going to be patched to use the kernel API in
case they are configured to. By default they will still be using their
internal implementation of the cryptographic algorithms. Of course there
still might be some applications (for example glibc libcrypt password
hashing) that decide to use the kernel interface directly, but these
will be a very small minority I think.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb

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

[Arnd Bergmann]

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?

> * Full compat_ioctl implementation

New drivers should be written to *avoid* compat_ioctl calls, using only
very simple fixed-length data structures as ioctl commands.

> * Version number added to the data format used when wrapping keys for storage

Again, wrong direction. If you think you need a version number, the interface
is probably not ready for inclusion yet. Make sure it is simple enough that
you don't run into the case where you have to make incompatible changes
that require API versioning.

>   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.
 
> Original patch set description follows.
> 
> These are the major differences compared to the BSD-like interface:
> 
> * The API supports key storage and management inside the kernel.
>   An application can thus ask the kernel to generate a key; the key is
>   then referenced via an integer identifier, and the application can be
>   prevented from accessing the raw key data.  Such a key can, if so configured,
>   still be wrapped for key transport to the recipient of the message, and
>   unwrapped by the recipient.

As Kyle mentioned, we already have a key management API in the kernel.
I think you should make a better effort of interfacing with that and
adding features you need to it, like a way to prevent the kernel from
handing out keys as you mentioned in your reply.

>   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.
 
> * 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.

OTOH, disabling ptrace with a root-only prctl should be an easy thing to
implement if there is a use case for it.

> Other advantages to having kernel crypto available to user space:
> 
> * User space will be able to take advantage of kernel drivers for hardware
>   crypto accelerators.

I can see this as a good reason to put a proper interface for asymmetric
crypto into the kernel. There are PCI cards and other things that are
supported using ad-hoc interfaces right now. It would be wonderful
if someone could clean that up and create a simple common interface that
covers all the hardware variants.
But that does not justify putting a software implementation into the kernel.

For symmetric crypto and hashing hardware acceleration is typically
implemented as CPU instructions anyway and available to user space
already, without the need for kernel support.

> * glibc, which in some configurations links to libfreebl3.so for hashes
>   necessary for crypt(), will be able to use the kernel implementation; this
>   means one less library to load and dynamically link for each such process.

If you are really worried about library load times, you can probably create
a patch that statically links libfreebl3 into glibc.

	Arnd

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

[Nikos Mavrogiannopoulos]

On 08/21/2010 07:08 PM, Arnd Bergmann 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 believe that this is the result of the discussion in the version 1 of
the proposal. The original API was specified with ioctls only.

>> * Full compat_ioctl implementation
> New drivers should be written to *avoid* compat_ioctl calls, using only
> very simple fixed-length data structures as ioctl commands.

There are cases where this cannot be easily done, when say pointers are
involved. IMHO forcing pointers to be u64 or u32 is dirtier than using
the compat interface.

>> * Version number added to the data format used when wrapping keys for storage
> Again, wrong direction. If you think you need a version number, the interface
> is probably not ready for inclusion yet. Make sure it is simple enough that
> you don't run into the case where you have to make incompatible changes
> that require API versioning.

Note that the version number is not to the interface but to data that
are intended for storage. It is desirable to have such a version there.

>>   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.

The same argument could apply to an other algorithm in the kernel such
as deflate, lzma, AES etc. There are cases that the benefits outweigh
the risks of adding them. I believe this is such a case.

>> These are the major differences compared to the BSD-like interface:
>> * The API supports key storage and management inside the kernel.
>>   An application can thus ask the kernel to generate a key; the key is
>>   then referenced via an integer identifier, and the application can be
>>   prevented from accessing the raw key data.  Such a key can, if so configured,
>>   still be wrapped for key transport to the recipient of the message, and
>>   unwrapped by the recipient.
> As Kyle mentioned, we already have a key management API in the kernel.
> I think you should make a better effort of interfacing with that and
> adding features you need to it, like a way to prevent the kernel from
> handing out keys as you mentioned in your reply.

Note that the NCR does not do key management. Integrating with the key
management API could be nice, but it is not something critical and is
not duplicating code or efforts in any way.

>>   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.

This is an alternative design. There quite some reasons against that,
such as the auditing features. For me the main reason was  that there
was no way to make it as fast (zero-copy) as this design, for the
requirements we had (interface with existing crypto libraries through
pkcs11). Zero-copy is important since crypto operations might involve
large chunks of data.

>> * 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.
> OTOH, disabling ptrace with a root-only prctl should be an easy thing to
> implement if there is a use case for it.

You are right. Debugging by the administrator was not an issue. Only
users should be prevented from that. It should have been mentioned.


regards,
Nikos

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

[Arnd Bergmann]

On Sunday 22 August 2010 09:52:14 Nikos Mavrogiannopoulos wrote:
> On 08/21/2010 07:08 PM, Arnd Bergmann wrote:
> > On Friday 20 August 2010 10:45:43 Miloslav Trmač wrote:

> >> * Full compat_ioctl implementation
> > New drivers should be written to *avoid* compat_ioctl calls, using only
> > very simple fixed-length data structures as ioctl commands.
> 
> There are cases where this cannot be easily done, when say pointers are
> involved. IMHO forcing pointers to be u64 or u32 is dirtier than using
> the compat interface.

Yes, but that only means you should avoid pointers in data structures
that are passed to ioctl. Ideally, you would use ioctl to control
the device while you use read and write to pass actual bits of data.

> >> * Version number added to the data format used when wrapping keys for storage
> > Again, wrong direction. If you think you need a version number, the interface
> > is probably not ready for inclusion yet. Make sure it is simple enough that
> > you don't run into the case where you have to make incompatible changes
> > that require API versioning.
> 
> Note that the version number is not to the interface but to data that
> are intended for storage. It is desirable to have such a version there.

ok, makes sense.

> >>   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.
> 
> The same argument could apply to an other algorithm in the kernel such
> as deflate, lzma, AES etc. There are cases that the benefits outweigh
> the risks of adding them. I believe this is such a case.

The algorithms that are in the kernel already are there specifically because
they are used by the kernel itself, which is an entirely different story.

> >>   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.
> 
> This is an alternative design. There quite some reasons against that,
> such as the auditing features. For me the main reason was  that there
> was no way to make it as fast (zero-copy) as this design, for the
> requirements we had (interface with existing crypto libraries through
> pkcs11). Zero-copy is important since crypto operations might involve
> large chunks of data.

You mean using a shared memory segment would not be possible without changing
the libpkcs11 interface?

	Arnd

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

[Nikos Mavrogiannopoulos]

On Mon, Aug 23, 2010 at 10:09 AM, Arnd Bergmann <arnd@arndb.de> wrote:

>> This is an alternative design. There quite some reasons against that,
>> such as the auditing features. For me the main reason was  that there
>> was no way to make it as fast (zero-copy) as this design, for the
>> requirements we had (interface with existing crypto libraries through
>> pkcs11). Zero-copy is important since crypto operations might involve
>> large chunks of data.
> You mean using a shared memory segment would not be possible without changing
> the libpkcs11 interface?

Indeed. The pkcs11 backend would have to copy the data to the shared
segment, thus high-performance applications requiring zero-copy, would
avoid to use this interface. Moreover if more than one applications
are using the interface, the shared segment it is going to be a
bottleneck. Having multiple shared segments might help, but I don't
know how practical is something like that with the posix ipc.

regards,
Nikos

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

[Pavel Machek]

Hi!

> Motivations for the extensions: governments are asking for more security
> features in the operating systems they procure, which make user-space
> implementations impractical.  A few examples:
> 
> * Advanced crypto module for OSPP for Common Criteria requires OS services
>   implementing several low-level crypto algorithms (e.g. AES, RSA).  This
>   requires the separation of crypto services from the consumer of those
>   services. (The threat model is that apps tend to have more vulnerabilities
>   than libraries and compromise of the app will lead to the ability to access
>   key material.) 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.

Hmm, root daemon seems like a way to go. You already do the switch
into the kernel... and "IPC is slow" is not good enough reason to put
everything in kernel. Plus, you should be able to get better usage of
multicore with daemon.

Numbers?
								Pavel


> * 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.
> 
> * GPOSPP requires auditing for crypto events (so does FIPS-140 level 2 cert).
>   To do this you need any crypto to have CAP_AUDIT_WRITE permissions which
>   means making everything that links to openssl, libgcrypt, or nss setuid
>   root. Making firefox and 400 other applications setuid root is a non-starter.
>   So, the solution is again to use crypto in the kernel where auditing needs no
>   special permissions.
> 
> Other advantages to having kernel crypto available to user space:
> 
> * User space will be able to take advantage of kernel drivers for hardware
>   crypto accelerators.
> 
> * glibc, which in some configurations links to libfreebl3.so for hashes
>   necessary for crypt(), will be able to use the kernel implementation; this
>   means one less library to load and dynamically link for each such process.
> 
> The code is derived from the original cryptodev-linux patch set; most of the
> new implementation was written by Nikos Mavrogiannopoulos
> <n.mavrogiannopoulos@gmail.com>.  Attributions are included in the respective
> source files.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

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

[Tomas Mraz]

On Wed, 2010-08-25 at 08:20 +0200, Pavel Machek wrote: 
> Hi!
> 
> > Motivations for the extensions: governments are asking for more security
> > features in the operating systems they procure, which make user-space
> > implementations impractical.  A few examples:
> > 
> > * Advanced crypto module for OSPP for Common Criteria requires OS services
> >   implementing several low-level crypto algorithms (e.g. AES, RSA).  This
> >   requires the separation of crypto services from the consumer of those
> >   services. (The threat model is that apps tend to have more vulnerabilities
> >   than libraries and compromise of the app will lead to the ability to access
> >   key material.) 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.
> 
> Hmm, root daemon seems like a way to go. You already do the switch
> into the kernel... and "IPC is slow" is not good enough reason to put
> everything in kernel. Plus, you should be able to get better usage of
> multicore with daemon.

Actually not, and the arguments why multicore would not be really used
better anyway were stated here as well. If an application needs some
cryptography function in most of the cases it has to wait for the
operation to finish before it can proceed  further. To use asynchronous
crypto interfaces efficiently would require serious redesign and rewrite
of the existing applications which is nowhere near to be accomplished.
In case of applications where the benefits of asynchronous crypto would
be obvious and easily utilized it is quite easier just to split the
threads for crypto processing and the rest of the application directly
inside the application process.
-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb

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

[Miloslav Trmac]

----- "Pavel Machek" <pavel@ucw.cz> wrote:
> > * Advanced crypto module for OSPP for Common Criteria requires OS services
> >   implementing several low-level crypto algorithms (e.g. AES, RSA).  This
> >   requires the separation of crypto services from the consumer of those
> >   services. (The threat model is that apps tend to have more vulnerabilities
> >   than libraries and compromise of the app will lead to the ability to access
> >   key material.) 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.
> 
> Hmm, root daemon seems like a way to go. You already do the switch
> into the kernel... and "IPC is slow" is not good enough reason to put
> everything in kernel. Plus, you should be able to get better usage of
> multicore with daemon.
> 
> Numbers?
Posted here before - adding a single syscall (to the one existing ioctl()) adds a 20% performance penalty when encrypting 256 bytes using cbc(aes).  Even with a 32KB block the penalty is 2.7%, and lots of crypto is done on quite small data sizes.

Inter-process IPC would have even higher overhead.

Using more cores is actually easier with the kernel implementation, where each crypto operation runs in the context of the calling task.  This naturally scales to the number of concurrent tasks; as Tomas has said, none of the existing crypto APIs naturally support parallel operations started by a single thread, so any performance advantage gained through this is unrealistic.  A daemon would have to explicitly create a thread for each core (and watch for CPU hotplug?), and the incoming requests would have to be distributed among the threads (with system-wide lock contention on the request queue/pipe/socket/whatever).
    Mirek