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 for Android: free password hash cracker in your pocket

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

Date:	Fri, 7 Jan 2011 08:16:46 +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 10:05:46AM -0800, Linus Torvalds wrote:
>
> Is there really any point to this? And can we get more explanation of
> what the interface is, and who would use it?

I think you've answered it yourself in the third paragraph :)

> If you need crypto in user space, it's almost invariably better done
> in user space. If the CPU can do crypto on its own, and doesn't expose
> those instructions to user space, it's just a stupid CPU - and the
> user/kernel transfer is likely going to make it slower than a pure
> software approach for any but the biggest transfers.

I agree completely.

> And if the crypto engine is off-chip, the sw version is going to be
> faster anyway except for possible async versions that are hard to
> interface to user space.
> 
> So I really need more convincing about the whole user-space interface.
> Adding new interfaces willy-nilly isn't a good idea. They need damn
> good reasons.

Right.  This purpose of this interface is to access the async
hardware crypto drivers that we have added over the past years.

For a modern x86-64 CPU it isn't interesting at all.  It's mainly
for other architectures where the CPU may not be able to keep up
with say 10Gb/s IPsec traffic and the encryption and/or hashing
must be offloaded.

This is also why only hash and skcipher are supported as they
are the main algorithm types supported by teh current async
drivers in the kernel.

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/