[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALCETrXhT=nm2o0yAzrKborYuaGZ7FD7MXh9UK=VHUa50PauEg@mail.gmail.com>
Date: Sat, 10 Dec 2016 09:48:24 -0800
From: Andy Lutomirski <luto@...capital.net>
To: "Jason A. Donenfeld" <Jason@...c4.com>, Al Viro <viro@...iv.linux.org.uk>
Cc: "kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>, Eric Biggers <ebiggers3@...il.com>,
linux-crypto@...r.kernel.org,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "linux-mm@...ck.org" <linux-mm@...ck.org>,
Andrew Lutomirski <luto@...nel.org>, Stephan Mueller <smueller@...onox.de>
Subject: Re: Re: Remaining crypto API regressions with CONFIG_VMAP_STACK
cc: Viro because I'm talking about iov_iter.
On Sat, Dec 10, 2016 at 6:45 AM, Jason A. Donenfeld <Jason@...c4.com> wrote:
> Hi Herbert,
>
> On Sat, Dec 10, 2016 at 6:37 AM, Herbert Xu <herbert@...dor.apana.org.au> wrote:
>> As for AEAD we never had a sync interface to begin with and I
>> don't think I'm going to add one.
>
> That's too bad to hear. I hope you'll reconsider. Modern cryptographic
> design is heading more and more in the direction of using AEADs for
> interesting things, and having a sync interface would be a lot easier
> for implementing these protocols. In the same way many protocols need
> a hash of some data, now protocols often want some particular data
> encrypted with an AEAD using a particular key and nonce and AD. One
> protocol that comes to mind is Noise [1].
>
I think that sync vs async has gotten conflated with
vectored-vs-nonvectored and the results are unfortunate.
There are a lot of users in the tree that are trying to do crypto on
very small pieces of data and want to have that data consist of the
concatenation of two small buffers and/or want to use primitives that
don't have "sync" interfaces. These users are stuck using async
interfaces even though using async implementations makes no sense for
them.
I'd love to see the API restructured a bit to decouple all of these
considerations. One approach might be to teach iov_iter about
scatterlists. Then, for each primitive, there could be two entry
points:
1. A simplified and lower-overhead entry. You pass it an iov_iter
(and, depending on what the operation is, an output iov_iter), it does
the crypto synchronously, and returns. Operating in-place might be
permitted for some primitives.
2. A full-featured async entry. You pass it iov_iters and it requires
that the iov_iters be backed by scatterlists in order to operate
asynchronously.
I see no reason that the decisions to use virtual vs physical
addressing or to do vectored vs non-vectored IO should be tied up with
asynchronicity.
--Andy
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
