LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Herbert Xu <herbert@gondor.apana.org.au>
To: Stephan Mueller <smueller@chronox.de>
Cc: "'Quentin Gouchet'" <quentin.gouchet@gmail.com>,
	Daniel Borkmann <dborkman@redhat.com>,
	linux-kernel@vger.kernel.org, linux-api@vger.kernel.org,
	linux-crypto@vger.kernel.org
Subject: Re: [PATCH v8 1/2] crypto: AF_ALG: add AEAD support
Date: Tue, 20 Jan 2015 14:00:17 +1100	[thread overview]
Message-ID: <20150120030017.GA10475@gondor.apana.org.au> (raw)
In-Reply-To: <1639027.yRSjDuRfFC@tachyon.chronox.de>

On Fri, Jan 09, 2015 at 04:30:45AM +0100, Stephan Mueller wrote:
> Am Donnerstag, 8. Januar 2015, 22:09:31 schrieb Herbert Xu:
> 
> Hi Herbert,
> 
> > On Wed, Jan 07, 2015 at 04:51:38PM +0100, Stephan Mueller wrote:
> > > +		if (!aead_writable(sk)) {
> > > +			/*
> > > +			 * If there is more data to be expected, but we cannot
> > > +			 * write more data, forcefully define that we do not
> > > +			 * expect more data to invoke the AEAD operation. This
> > > +			 * prevents a deadlock in user space.
> > > +			 */
> > > +			ctx->more = 0;
> > 
> > We should return EMSGSIZE here.  Also we should clear out the
> > existing data so that the socket may be reused again.
> 
> Is this really wise considering that we want to support a threaded caller? For 
> example, one thread sends data and another reads data. For some reason, the 
> reading thread is throttled or slower than the sender. Now, with the current 
> solution, the sender is put on hold (i.e. throttled) until the reader can 
> catch up. I.e. we have an automated synchronization between sender/receiver.
> 
> Thus, when we remove the wait here and return an error, the sender will be 
> shut down and there is no synchronization of the reader/writer any more.
> 
> Note, the same applies to the very similar code in aead_sendpage too.

No, if we're in this case then something seriously wrong has
happened.  IOW the application writer has screwed up.  We're
not able to carry out the wish of user-space because of resource
limits on the socket.  Attempting to continue at this point will
only cause confusion.

So we should loudly declare that there was an error.

> > > +	ctx->more = msg->msg_flags & MSG_MORE;
> > > +	if (!ctx->more && !aead_sufficient_data(ctx))
> > > +		err = -EINVAL;
> > 
> > Ditto, we should discard the data that's queued up.  Also perhaps
> > use EBADMSG instead of EINVAL.
> 
> Agreed that we should clear out the buffer. I will provide that in the next 
> release for both, the sendmsg and sendpage implementations.
> 
> However, I am not sure whether using EBADMSG is a good idea. The error of 
> EBADMSG in the kernel crypto API is only used for integrity errors of AEAD 
> ciphers. But our error case here has nothing to do with the integrity error.
> 
> I would be fine with any other error number -- EMSGSIZE as you suggested 
> above?

Sure.

> Do you think whether such approach makes sense? If yes, which limit to the 
> number of rsgl should we apply -- is ALG_MAX_PAGES good?

Yes I think your solution in v10 is fine.  The current kernel
AEAD interface isn't the best but we're stuck with it for the
time being so this is the best we can do.

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

  reply	other threads:[~2015-01-20  3:00 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-07 15:51 [PATCH v8 0/2] crypto: AF_ALG: add AEAD and RNG support Stephan Mueller
2015-01-07 15:51 ` [PATCH v8 1/2] crypto: AF_ALG: add AEAD support Stephan Mueller
2015-01-08 11:09   ` Herbert Xu
2015-01-09  3:30     ` Stephan Mueller
2015-01-20  3:00       ` Herbert Xu [this message]
2015-01-20  3:08         ` Stephan Mueller
2015-01-07 15:52 ` [PATCH v8 2/2] crypto: AF_ALG: enable AEAD interface compilation Stephan Mueller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150120030017.GA10475@gondor.apana.org.au \
    --to=herbert@gondor.apana.org.au \
    --cc=dborkman@redhat.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=quentin.gouchet@gmail.com \
    --cc=smueller@chronox.de \
    --subject='Re: [PATCH v8 1/2] crypto: AF_ALG: add AEAD support' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).