All of lore.kernel.org
 help / color / mirror / Atom feed
From: liushuoran <liushuoran@huawei.com>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Xiakaixu <xiakaixu@huawei.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>,
	"David S. Miller" <davem@davemloft.net>,
	"Theodore Ts'o" <tytso@mit.edu>, Jaegeuk Kim <jaegeuk@kernel.org>,
	"nhorman@tuxdriver.com" <nhorman@tuxdriver.com>,
	"mh1@iki.fi" <mh1@iki.fi>,
	"linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Wangbintian <bintian.wang@huawei.com>,
	Huxinwei <huxinwei@huawei.com>,
	"zhangzhibin (C)" <zhangzhibin.zhang@huawei.com>
Subject: RE: Kernel panic - encryption/decryption failed when open file on Arm64
Date: Mon, 12 Sep 2016 02:16:30 +0000	[thread overview]
Message-ID: <00B10D30F2BAA743B48953A4D86C96D54C8A8A@SZXEMI506-MBS.china.huawei.com> (raw)
In-Reply-To: <CAKv+Gu8w+BuwxQjOtpnFPHnJNUzq7m0K+KJ8=FG2wHigaB54ng@mail.gmail.com>

Hi Ard,

Thanks for the prompt reply. With the patch, there is no panic anymore. But it seems that the encryption/decryption is not successful anyway.

As Herbert points out, "If the page allocation fails in blkcipher_walk_next it'll simply switch over to processing it block by block". So does that mean the encryption/decryption should be successful even if the page allocation fails? Please correct me if I misunderstand anything. Thanks in advance.

Regards,
Shuoran

> -----Original Message-----
> From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org]
> Sent: Friday, September 09, 2016 6:57 PM
> To: Xiakaixu
> Cc: Herbert Xu; David S. Miller; Theodore Ts'o; Jaegeuk Kim;
> nhorman@tuxdriver.com; mh1@iki.fi; linux-crypto@vger.kernel.org;
> linux-kernel@vger.kernel.org; Wangbintian; liushuoran; Huxinwei; zhangzhibin
> (C)
> Subject: Re: Kernel panic - encryption/decryption failed when open file on
> Arm64
> 
> On 9 September 2016 at 11:31, Ard Biesheuvel <ard.biesheuvel@linaro.org>
> wrote:
> > On 9 September 2016 at 11:19, xiakaixu <xiakaixu@huawei.com> wrote:
> >> Hi,
> >>
> >> After a deeply research about this crash, seems it is a specific
> >> bug that only exists in armv8 board. And it occurs in this function
> >> in arch/arm64/crypto/aes-glue.c.
> >>
> >> static int ctr_encrypt(struct blkcipher_desc *desc, struct scatterlist *dst,
> >>                        struct scatterlist *src, unsigned int nbytes)
> >> {
> >>        ...
> >>
> >>         desc->flags &= ~CRYPTO_TFM_REQ_MAY_SLEEP;
> >>         blkcipher_walk_init(&walk, dst, src, nbytes);
> >>         err = blkcipher_walk_virt_block(desc, &walk, AES_BLOCK_SIZE);
> --->
> >> page allocation failed
> >>
> >>         ...
> >>
> >>         while ((blocks = (walk.nbytes / AES_BLOCK_SIZE)))
> {           ---->
> >> walk.nbytes = 0, and skip this loop
> >>                 aes_ctr_encrypt(walk.dst.virt.addr, walk.src.virt.addr,
> >>                                 (u8 *)ctx->key_enc, rounds, blocks,
> walk.iv,
> >>                                 first);
> >>         ...
> >>                 err = blkcipher_walk_done(desc, &walk,
> >>                                           walk.nbytes %
> AES_BLOCK_SIZE);
> >>         }
> >>         if (nbytes)
> {                                                 ---->
> >> enter this if() statement
> >>                 u8 *tdst = walk.dst.virt.addr + blocks * AES_BLOCK_SIZE;
> >>                 u8 *tsrc = walk.src.virt.addr + blocks * AES_BLOCK_SIZE;
> >>         ...
> >>
> >>                 aes_ctr_encrypt(tail, tsrc, (u8 *)ctx->key_enc, rounds,
> >> ----> the the sencond input parameter is NULL, so crash...
> >>                                 blocks, walk.iv, first);
> >>         ...
> >>         }
> >>         ...
> >> }
> >>
> >>
> >> If the page allocation failed in the function blkcipher_walk_virt_block(),
> >> the variable walk.nbytes = 0, so it will skip the while() loop and enter
> >> the if(nbytes) statment. But here the varibale tsrc is NULL and it is also
> >> the sencond input parameter of the function aes_ctr_encrypt()... Kernel
> >> Panic...
> >>
> >> I have also researched the similar function in other architectures, and
> >> there if(walk.nbytes) is used, not this if(nbytes) statement in the armv8.
> >> so I think this armv8 function ctr_encrypt() should deal with the page
> >> allocation failed situation.
> >>
> 
> Does this solve your problem?
> 
> diff --git a/arch/arm64/crypto/aes-glue.c b/arch/arm64/crypto/aes-glue.c
> index 5c888049d061..6b2aa0fd6cd0 100644
> --- a/arch/arm64/crypto/aes-glue.c
> +++ b/arch/arm64/crypto/aes-glue.c
> @@ -216,7 +216,7 @@ static int ctr_encrypt(struct blkcipher_desc
> *desc, struct scatterlist *dst,
>                 err = blkcipher_walk_done(desc, &walk,
>                                           walk.nbytes % AES_BLOCK_SIZE);
>         }
> -       if (nbytes) {
> +       if (walk.nbytes % AES_BLOCK_SIZE) {
>                 u8 *tdst = walk.dst.virt.addr + blocks * AES_BLOCK_SIZE;
>                 u8 *tsrc = walk.src.virt.addr + blocks * AES_BLOCK_SIZE;
>                 u8 __aligned(8) tail[AES_BLOCK_SIZE];

  reply	other threads:[~2016-09-12  2:16 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <57D15BD3.40903@huawei.com>
2016-09-08 12:47 ` Kernel panic - encryption/decryption failed when open file on Arm64 Herbert Xu
2016-09-09  4:08   ` xiakaixu
2016-09-09 10:19   ` xiakaixu
2016-09-09 10:31     ` Ard Biesheuvel
2016-09-09 10:56       ` Ard Biesheuvel
2016-09-12  2:16         ` liushuoran [this message]
2016-09-12 17:40           ` Ard Biesheuvel
2016-09-13  2:05             ` xiakaixu
2016-09-13  6:43             ` Herbert Xu
2016-09-13  7:56               ` Ard Biesheuvel

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=00B10D30F2BAA743B48953A4D86C96D54C8A8A@SZXEMI506-MBS.china.huawei.com \
    --to=liushuoran@huawei.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=bintian.wang@huawei.com \
    --cc=davem@davemloft.net \
    --cc=herbert@gondor.apana.org.au \
    --cc=huxinwei@huawei.com \
    --cc=jaegeuk@kernel.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mh1@iki.fi \
    --cc=nhorman@tuxdriver.com \
    --cc=tytso@mit.edu \
    --cc=xiakaixu@huawei.com \
    --cc=zhangzhibin.zhang@huawei.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.