netdev - Re: RFC: Crypto API User-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-next>] [day] [month] [year] [list]

Date:	Tue, 7 Sep 2010 07:27:47 -0400 (EDT)
From:	Miloslav Trmac <mitr@...hat.com>
To:	Herbert Xu <herbert@...dor.hengli.com.au>
Cc:	Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
	netdev@...r.kernel.org
Subject: Re: RFC: Crypto API User-interface

Hello,
----- "Herbert Xu" <herbert@...dor.hengli.com.au> wrote:
> First of all let's have a quick look at what the user-space side
> looks like for AEAD:
> 
> 	/* Each listen call generates one or more fds for input/output
> 	 * that behave like pipes.
> 	 */
> 	listen(tfmfd, 0);
> 	/* fd for encryption/decryption */
> 	opfd = accept(tfmfd, NULL, 0);
> 	/* fd for associated data */
> 	adfd = accept(tfmfd, NULL, 0);
If nothing else, two consecutive accept() calls with different semantics go rather strongly against the spirit of the socket API IMHO.

> 	/* These may also be set through sendmsg(2) cmsgs. */
> 	op = ALG_AEAD_OP_ENCRYPT;
> 	setsockopt(opfd, SOL_ALG, ALG_AEAD_OP, op, sizeof(op));
> 	setsockopt(opfd, SOL_ALG, ALG_AEAD_SET_IV, iv, ivlen);
So that is 8 syscalls to initialize a single AEAD operation.
 
> 	/* Like pipes, larges writes will block!
> 	 * For AEAD, ensure the socket buffer is large enough.
> 	 * For ciphers, whenever the write blocks start reading.
> 	 * For hashes, writes should never block.
> 	 */
How does one know the buffer is large enough?

"Whenever the write blocks start reading" turns a trivial loop submitting one buffer-size at a time into something that would be much easier to get wrong.


> 	/* Zero-copy */
> 	splice(cryptfd, NULL, opfd, NULL, datalen,
> SPLICE_F_MOVE|SPLIFE_F_MORE);
So that is "zero copy on input if your data come from a file descriptor"?  I'm not sure many applications will be able to take advantage of that, and there's still the output copy.

Also, is SPLICE_F_MOVE actually implemented?

Why use splice() at all?  Simple write() gives the driver the __user pointers that can be used to access the underlying pages directly.  Yanking user-space pages out from the process address space to make them "owned" by the crypto driver, causing more page faults when the process wants to reuse the buffer, does not seem like a performance improvement.

> Please comment.
I can't really see any advantage in trying to use existing syscalls for crypto when the syscalls were clearly not intended for the purpose.  setsockopt() is fine for sockets because options are set up once per connection, and the connection very rarely lasts less than several milliseconds; crypto operation options have to be configured much more often.

7 syscalls to compute a single hash is very difficult to accept.
     Mirek
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html