linux-crypto.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jan Glauber <jan.glauber@gmail.com>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
	Jan Glauber <jang@linux.vnet.ibm.com>
Subject: Re: crypto: s390 - Fix aes-cbc IV corruption
Date: Thu, 14 Nov 2013 17:10:20 +0100	[thread overview]
Message-ID: <20131114161020.GA19229@hal> (raw)
In-Reply-To: <20131031032547.GA16528@gondor.apana.org.au>

On Thu, Oct 31, 2013 at 11:25:47AM +0800, Herbert Xu wrote:
> Hi:

Hi Herbert,

just seen this as my old email address is dead... Your patch looks
fine as it keeps the iv and the key together as required by the instruction.

However, I'm curious how this could be racy with threads. The encryption must
be serialized because of the chaining. The decryption could in theory happen
in parallel, but is this the case here?

--Jan

> The cbc-aes-s390 algorithm incorrectly places the IV in the tfm
> data structure.  As the tfm is shared between multiple threads,
> this introduces a possibility of data corruption.
> 
> This patch fixes this by moving the parameter block containing
> the IV and key onto the stack (the block is 48 bytes long).
> 
> The same bug exists elsewhere in the s390 crypto system and they
> will be fixed in subsequent patches.
> 
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
> 
> diff --git a/arch/s390/crypto/aes_s390.c b/arch/s390/crypto/aes_s390.c
> index b4dbade..2e4b5be 100644
> --- a/arch/s390/crypto/aes_s390.c
> +++ b/arch/s390/crypto/aes_s390.c
> @@ -35,7 +35,6 @@ static u8 *ctrblk;
>  static char keylen_flag;
>  
>  struct s390_aes_ctx {
> -	u8 iv[AES_BLOCK_SIZE];
>  	u8 key[AES_MAX_KEY_SIZE];
>  	long enc;
>  	long dec;
> @@ -441,30 +440,36 @@ static int cbc_aes_set_key(struct crypto_tfm *tfm, const u8 *in_key,
>  	return aes_set_key(tfm, in_key, key_len);
>  }
>  
> -static int cbc_aes_crypt(struct blkcipher_desc *desc, long func, void *param,
> +static int cbc_aes_crypt(struct blkcipher_desc *desc, long func,
>  			 struct blkcipher_walk *walk)
>  {
> +	struct s390_aes_ctx *sctx = crypto_blkcipher_ctx(desc->tfm);
>  	int ret = blkcipher_walk_virt(desc, walk);
>  	unsigned int nbytes = walk->nbytes;
> +	struct {
> +		u8 iv[AES_BLOCK_SIZE];
> +		u8 key[AES_MAX_KEY_SIZE];
> +	} param;
>  
>  	if (!nbytes)
>  		goto out;
>  
> -	memcpy(param, walk->iv, AES_BLOCK_SIZE);
> +	memcpy(param.iv, walk->iv, AES_BLOCK_SIZE);
> +	memcpy(param.key, sctx->key, sctx->key_len);
>  	do {
>  		/* only use complete blocks */
>  		unsigned int n = nbytes & ~(AES_BLOCK_SIZE - 1);
>  		u8 *out = walk->dst.virt.addr;
>  		u8 *in = walk->src.virt.addr;
>  
> -		ret = crypt_s390_kmc(func, param, out, in, n);
> +		ret = crypt_s390_kmc(func, &param, out, in, n);
>  		if (ret < 0 || ret != n)
>  			return -EIO;
>  
>  		nbytes &= AES_BLOCK_SIZE - 1;
>  		ret = blkcipher_walk_done(desc, walk, nbytes);
>  	} while ((nbytes = walk->nbytes));
> -	memcpy(walk->iv, param, AES_BLOCK_SIZE);
> +	memcpy(walk->iv, param.iv, AES_BLOCK_SIZE);
>  
>  out:
>  	return ret;
> @@ -481,7 +486,7 @@ static int cbc_aes_encrypt(struct blkcipher_desc *desc,
>  		return fallback_blk_enc(desc, dst, src, nbytes);
>  
>  	blkcipher_walk_init(&walk, dst, src, nbytes);
> -	return cbc_aes_crypt(desc, sctx->enc, sctx->iv, &walk);
> +	return cbc_aes_crypt(desc, sctx->enc, &walk);
>  }
>  
>  static int cbc_aes_decrypt(struct blkcipher_desc *desc,
> @@ -495,7 +500,7 @@ static int cbc_aes_decrypt(struct blkcipher_desc *desc,
>  		return fallback_blk_dec(desc, dst, src, nbytes);
>  
>  	blkcipher_walk_init(&walk, dst, src, nbytes);
> -	return cbc_aes_crypt(desc, sctx->dec, sctx->iv, &walk);
> +	return cbc_aes_crypt(desc, sctx->dec, &walk);
>  }
>  
>  static struct crypto_alg cbc_aes_alg = {
> 
> 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
> --
> To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2013-11-14 16:10 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-31  3:25 crypto: s390 - Fix aes-cbc IV corruption Herbert Xu
2013-11-14 16:10 ` Jan Glauber [this message]
2013-11-17 12:33   ` Herbert Xu

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=20131114161020.GA19229@hal \
    --to=jan.glauber@gmail.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=jang@linux.vnet.ibm.com \
    --cc=linux-crypto@vger.kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).