Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp265068yba; Mon, 20 May 2019 08:20:28 -0700 (PDT) X-Google-Smtp-Source: APXvYqyQsOYDMFMP86b5mRCv6134xG7DyvOia/yFquoGhbf4ApFTuuaMu8wefNUrpqYWzAxgYyvp X-Received: by 2002:a17:902:3281:: with SMTP id z1mr23913414plb.44.1558365628215; Mon, 20 May 2019 08:20:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1558365628; cv=none; d=google.com; s=arc-20160816; b=PFQfbcfo3xr6qU50LOYv7xb56cHWJH8iwVuqDDndHTYT04oNtclqm/V2DwRu9j45+C oIn3h0YqacADINB9mUM2uM7Wv75vUFoubnv3vwx7DGm08WWd30guS6JFiDc1tkmDf6f+ jEJhT64tcOi74wW5o+lQ5sNrMLMLEnS69jTX+Hqix+EHbEpxwRZiNVKN/QK/+VX0l5BP 1sy2f8IOIt+ncJNZkp9oLRltU2DR4zg3iv5xFeqCfRohBfeFwIPqf+j08M2EsAwl/a/Z ReuFZ6bYxC492+TC0fUmhVDKhX1x+DpnhXfVMX1vm28+iNiXtofmw8Z2EXVFU4Ba+VZd x2Rw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=pGE/k7oTergupyvIvkF27UBNrX2+MnkWXBTHaUbZvTw=; b=eyh5ro7sCcmXf3PcwEDFJ9Tij3dIwjSCAcncAdTrUJUxW8MD0eYYRRB+yeLqpvshO5 ii2ieP2o2Dov1V9e4ZMSjqAitAdt6dxqHyv7uMtcdg+PKYmW5Mamugr65weE6AB6+ckx hkYH+Uxd7GFqf6kkuqPdg3AegvUFh2CKyMUHMSj3so6qlO5ocfl3NILaZDkszysspU4f bJzf5fekIuWP7qvby7nEjEjpuE2bi+XHs93zw7FNMrWZRII87ZXbgjSiBEmVRJvni9zx 1oeJj2taPLG33cTxpUI0BwexX4Rlq18nSo5W1gAN/kJ7ndiodvjFAWK+qb9IXIMZEFvv 2BOw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=S6CAKL4f; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c134si10294402pga.268.2019.05.20.08.20.13; Mon, 20 May 2019 08:20:28 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=S6CAKL4f; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732281AbfETMVm (ORCPT + 99 others); Mon, 20 May 2019 08:21:42 -0400 Received: from mail.kernel.org ([198.145.29.99]:35326 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388185AbfETMVd (ORCPT ); Mon, 20 May 2019 08:21:33 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 00AAF2173C; Mon, 20 May 2019 12:21:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1558354892; bh=6e8PlO5lwAHj8M3A4ZeTkocqPZqdI1Jv0XXMOD8pH0g=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=S6CAKL4fa55G6dUau7VU0DPtAyOcwQtMCb5wBJA7WKPmjAV9X2RCtdtaXDhkinEav ChbcOHDdehy+W+LZS1QNcbrydikxnIJTiKrKbDdLONkq1PX9r4/yNMH7VD/FlL1NE4 9AHljbgLUoWggXpYnOEpFvf/pWNXe9bfKYBWCHlE= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Christian Lamparter , Herbert Xu Subject: [PATCH 4.19 019/105] crypto: crypto4xx - fix cfb and ofb "overran dst buffer" issues Date: Mon, 20 May 2019 14:13:25 +0200 Message-Id: <20190520115248.346000022@linuxfoundation.org> X-Mailer: git-send-email 2.21.0 In-Reply-To: <20190520115247.060821231@linuxfoundation.org> References: <20190520115247.060821231@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Christian Lamparter commit 7e92e1717e3eaf6b322c252947c696b3059f05be upstream. Currently, crypto4xx CFB and OFB AES ciphers are failing testmgr's test vectors. |cfb-aes-ppc4xx encryption overran dst buffer on test vector 3, cfg="in-place" |ofb-aes-ppc4xx encryption overran dst buffer on test vector 1, cfg="in-place" This is because of a very subtile "bug" in the hardware that gets indirectly mentioned in 18.1.3.5 Encryption/Decryption of the hardware spec: the OFB and CFB modes for AES are listed there as operation modes for >>> "Block ciphers" <<<. Which kind of makes sense, but we would like them to be considered as stream ciphers just like the CTR mode. To workaround this issue and stop the hardware from causing "overran dst buffer" on crypttexts that are not a multiple of 16 (AES_BLOCK_SIZE), we force the driver to use the scatter buffers as the go-between. As a bonus this patch also kills redundant pd_uinfo->num_gd and pd_uinfo->num_sd setters since the value has already been set before. Cc: stable@vger.kernel.org Fixes: f2a13e7cba9e ("crypto: crypto4xx - enable AES RFC3686, ECB, CFB and OFB offloads") Signed-off-by: Christian Lamparter Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman --- drivers/crypto/amcc/crypto4xx_core.c | 31 +++++++++++++++++++++---------- 1 file changed, 21 insertions(+), 10 deletions(-) --- a/drivers/crypto/amcc/crypto4xx_core.c +++ b/drivers/crypto/amcc/crypto4xx_core.c @@ -712,7 +712,23 @@ int crypto4xx_build_pd(struct crypto_asy size_t offset_to_sr_ptr; u32 gd_idx = 0; int tmp; - bool is_busy; + bool is_busy, force_sd; + + /* + * There's a very subtile/disguised "bug" in the hardware that + * gets indirectly mentioned in 18.1.3.5 Encryption/Decryption + * of the hardware spec: + * *drum roll* the AES/(T)DES OFB and CFB modes are listed as + * operation modes for >>> "Block ciphers" <<<. + * + * To workaround this issue and stop the hardware from causing + * "overran dst buffer" on crypttexts that are not a multiple + * of 16 (AES_BLOCK_SIZE), we force the driver to use the + * scatter buffers. + */ + force_sd = (req_sa->sa_command_1.bf.crypto_mode9_8 == CRYPTO_MODE_CFB + || req_sa->sa_command_1.bf.crypto_mode9_8 == CRYPTO_MODE_OFB) + && (datalen % AES_BLOCK_SIZE); /* figure how many gd are needed */ tmp = sg_nents_for_len(src, assoclen + datalen); @@ -730,7 +746,7 @@ int crypto4xx_build_pd(struct crypto_asy } /* figure how many sd are needed */ - if (sg_is_last(dst)) { + if (sg_is_last(dst) && force_sd == false) { num_sd = 0; } else { if (datalen > PPC4XX_SD_BUFFER_SIZE) { @@ -805,9 +821,10 @@ int crypto4xx_build_pd(struct crypto_asy pd->sa_len = sa_len; pd_uinfo = &dev->pdr_uinfo[pd_entry]; - pd_uinfo->async_req = req; pd_uinfo->num_gd = num_gd; pd_uinfo->num_sd = num_sd; + pd_uinfo->dest_va = dst; + pd_uinfo->async_req = req; if (iv_len) memcpy(pd_uinfo->sr_va->save_iv, iv, iv_len); @@ -826,7 +843,6 @@ int crypto4xx_build_pd(struct crypto_asy /* get first gd we are going to use */ gd_idx = fst_gd; pd_uinfo->first_gd = fst_gd; - pd_uinfo->num_gd = num_gd; gd = crypto4xx_get_gdp(dev, &gd_dma, gd_idx); pd->src = gd_dma; /* enable gather */ @@ -863,17 +879,14 @@ int crypto4xx_build_pd(struct crypto_asy * Indicate gather array is not used */ pd_uinfo->first_gd = 0xffffffff; - pd_uinfo->num_gd = 0; } - if (sg_is_last(dst)) { + if (!num_sd) { /* * we know application give us dst a whole piece of memory * no need to use scatter ring. */ pd_uinfo->using_sd = 0; pd_uinfo->first_sd = 0xffffffff; - pd_uinfo->num_sd = 0; - pd_uinfo->dest_va = dst; sa->sa_command_0.bf.scatter = 0; pd->dest = (u32)dma_map_page(dev->core_dev->device, sg_page(dst), dst->offset, @@ -887,9 +900,7 @@ int crypto4xx_build_pd(struct crypto_asy nbytes = datalen; sa->sa_command_0.bf.scatter = 1; pd_uinfo->using_sd = 1; - pd_uinfo->dest_va = dst; pd_uinfo->first_sd = fst_sd; - pd_uinfo->num_sd = num_sd; sd = crypto4xx_get_sdp(dev, &sd_dma, sd_idx); pd->dest = sd_dma; /* setup scatter descriptor */