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

On Wed, 2010-08-25 at 08:20 +0200, Pavel Machek wrote: 

Hi!

quoted

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