linux-kernel - Re: Crypto Update for 2.6.38

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: <20110106223042.GA27080@gondor.apana.org.au>
Date:	Fri, 7 Jan 2011 09:30:42 +1100
From:	Herbert Xu <herbert@...dor.apana.org.au>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	"David S. Miller" <davem@...emloft.net>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Linux Crypto Mailing List <linux-crypto@...r.kernel.org>
Subject: Re: Crypto Update for 2.6.38

On Thu, Jan 06, 2011 at 02:13:17PM -0800, Linus Torvalds wrote:
> 
> But I'm still missing the part where you show that there is any actual
> use case that makes sense, and that actually improves performance.
> Maybe it's been posted somewhere else, but the thing is, you're asking
> _me_ to pull, and as a result you need to convince _me_ that this is a
> good idea. So if it's been posted/discussed extensively elsewhere,
> please point to those discussions.

The main use-case is bulk encryption/hashing in user-space.  For
example, on Sparc Niagara2 you need to use SPU (Stream Processing
Unit) in order to do crypto at 10Gb/s over the network.  Because
of the hardware design, it is difficult to make use of the SPU
directly in user-space, unless you dedicate the SPU to one single
thread/user.

That is why we need a crypto driver in the kernel as well as a
user-space interface exporting it, to make available a single
piece of hardware resource so that it may be used by multiple
users in user-space.

The same applies to most of the drivers in drivers/crypto, e.g.,
omap provides ARM crypto acceleration providing crypto throughput
that simply cannot be achieved by the CPU itself.

The actual encryption in user-space would be anything that is
done in bulk, such as SSH or SSL.  In fact, the intention is
to implement it just once in a library such as libssl where it
could then be used automatically by all appliations.

> But in your example, it looks like you just give it the key. Which to
> me means that you're totally missing one of the major reasons for
> having a separate protection domain.

Providing such separation is not the primary objective of this API,
which is providing user-space access to off-chip crypto hardware.

However, this is something that has been considered and can be
easily added.  The idea is to first add symmetric key storage
capability to the existing in-kernel keyring API.  Once that is
done we can easily add a new setsockopt to the crypto user-interface
that retrieves the key from the kernel keyring instead of getting
it directly from user-space.

Cheers,
-- 
Email: Herbert Xu <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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/