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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1282718679.2930.42.camel@vespa.frost.loc>
Date:	Wed, 25 Aug 2010 08:44:39 +0200
From:	Tomas Mraz <tmraz@...hat.com>
To:	Pavel Machek <pavel@....cz>
Cc:	Miloslav Trma? <mitr@...hat.com>,
	Herbert Xu <herbert@...dor.hengli.com.au>,
	linux-crypto@...r.kernel.org,
	Nikos Mavrogiannopoulos <n.mavrogiannopoulos@...il.com>,
	Neil Horman <nhorman@...hat.com>, linux-kernel@...r.kernel.org
Subject: 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!
> 
> > 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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/