Linux cryptographic layer development
 help / color / mirror / Atom feed
From: Herbert Xu <herbert@gondor.apana.org.au>
To: Stephan Mueller <smueller@chronox.de>
Cc: Linux Crypto Mailing List <linux-crypto@vger.kernel.org>
Subject: Re: crypto: algif_aead - Switch to new AEAD interface
Date: Fri, 29 May 2015 21:28:40 +0800	[thread overview]
Message-ID: <20150529132840.GA20596@gondor.apana.org.au> (raw)
In-Reply-To: <2444206.rbm5Z3UBF9@tachyon.chronox.de>

On Fri, May 29, 2015 at 12:09:35PM +0200, Stephan Mueller wrote:
> 
> > -	return (ctx->used >= (ctx->aead_assoclen + (ctx->enc ? 0 : as)));
> > +	return ctx->used >= ctx->aead_assoclen + as;
> 
> This change requires that the buffer handed in by user space always has room 
> for the tag, regardless whether it is needed or not. Is that intended?

Yes for two reasons.  One is that sometimes we need to enforce
in-place processing, in which case dst must be at least as big
as src.  The other reason is to eventually allow in-place processing
through algif_aead.  Unless the two SG lists were of the same length,
it isn't possible to do that.

> > -		/* add the size needed for the auth tag to be created */
> > -		outlen += as;
> > -	} else {
> > -		/* output data size is input without the authentication tag */
> > -		outlen = used - as;
> 
> The removal of these make me wonder: with those missing, the output of the 
> cipher operation does not have CT || tag (in case of encryption) or PT (in 
> case of encryption.
> 
> Note, I have updated my user space code to require space for the AD in the 
> output buffer. When reverting those changes with the following patch, the code 
> works nicely. If I do not apply the patch, the beginning of the CT or PT is as 
> expected, but the end is bogus. Also, the tag would be missing.

Well used is now supposed to always contain the tag in both cases.

Can you send me the code that you're using to test this and I'll
do some tests on it.
 
> However, when use those changes and I perform the test of libkcapi/test/kcapi 
> -y -s, I get the following strange crash which i have no idea where to look 
> for the cause (normal sendmsg and vmsplice tests with libkcapi/test/kcapi -y 
> and libkcapi/test/kcapi -y -v work flawless)

This is clearly not good.  It looks like memory corruption.

Thanks,
-- 
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-05-29 13:28 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-27  9:24 crypto: algif_aead - Switch to new AEAD interface Herbert Xu
2015-05-27 10:10 ` Stephan Mueller
2015-05-27 10:14   ` Herbert Xu
2015-05-29 10:09 ` Stephan Mueller
2015-05-29 13:28   ` Herbert Xu [this message]
2015-05-29 14:50     ` Stephan Mueller
2015-05-29 21:32       ` 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=20150529132840.GA20596@gondor.apana.org.au \
    --to=herbert@gondor.apana.org.au \
    --cc=linux-crypto@vger.kernel.org \
    --cc=smueller@chronox.de \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox