From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754158AbcIIKVL (ORCPT ); Fri, 9 Sep 2016 06:21:11 -0400 Received: from szxga02-in.huawei.com ([119.145.14.65]:53125 "EHLO szxga02-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753777AbcIIKUX (ORCPT ); Fri, 9 Sep 2016 06:20:23 -0400 Subject: Re: Kernel panic - encryption/decryption failed when open file on Arm64 To: Herbert Xu References: <57D15BD3.40903@huawei.com> <20160908124709.GA26586@gondor.apana.org.au> CC: , , , , , , , , Bintian , , Huxinwei , From: xiakaixu Message-ID: <57D28CB8.4080904@huawei.com> Date: Fri, 9 Sep 2016 18:19:36 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160908124709.GA26586@gondor.apana.org.au> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.111.182.180] X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.57D28CC5.0162,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: c6ee192a3a0758c6d6ad05a2567cdf46 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. Regards Kaixu Xia > On Thu, Sep 08, 2016 at 08:38:43PM +0800, xiakaixu wrote: >> Hi, >> >> I am using the encryption/decryption feature on arm64 board and a kernel >> panic occurs just when open a file. As the memory size of the board >> is limited >> and there are some page allocation failures before the panic. >> >> Seems it is a kernel bug from the call trace log. >> >> ... >> - fscrypt_get_encryption_info >> - get_crypt_info.part.1 >> - validate_user_key.isra.0 >> - derive_aes_gcm_key >> - crypto_gcm_decrypt >> - ablk_decrypt >> - ctr_encrypt >> - blkcipher_walk_done >> - blkcipher_walk_next >> - __get_free_pages >> ----------------------------------> page allocation failure >> ... >> - aes_ctr_encrypt >> -----------------------------------------> the input parameter is >> NULL pointer as the page allocation failure >> >> >> The input parameter of function aes_ctr_encrypt() comes from the >> /struct blkcipher_walk// >> //walk/, and this variable /walk /is allocated by the function >> __get_free_pages(). So if this >> page allocate failed, the input parameter of function >> aes_ctr_encrypt() will be NULL. The >> panic will occurs if we don't check the input parameter. >> >> Not sure about this and wish to get your opinions! > > If the page allocation fails in blkcipher_walk_next it'll simply > switch over to processing it block by block. so I don't think the > warning is related to the crash. > > Cheers, >