From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753945AbdFSKbe (ORCPT ); Mon, 19 Jun 2017 06:31:34 -0400 Received: from mail-db5eur01on0066.outbound.protection.outlook.com ([104.47.2.66]:11435 "EHLO EUR01-DB5-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753830AbdFSKbc (ORCPT ); Mon, 19 Jun 2017 06:31:32 -0400 From: =?iso-8859-2?Q?Horia_Geant=E3?= To: David Gstir , Dan Douglass , "herbert@gondor.apana.org.au" , "davem@davemloft.net" CC: "richard@sigma-star.at" , "linux-crypto@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: Re: [RFC PATCH 1/2] crypto: caam - properly set IV after {en,de}crypt Thread-Topic: [RFC PATCH 1/2] crypto: caam - properly set IV after {en,de}crypt Thread-Index: AQHS25tD5/IlvDCJWU6z2t8m/ePXKQ== Date: Mon, 19 Jun 2017 10:31:27 +0000 Message-ID: References: <20170602122446.2427-1-david@sigma-star.at> <20170602122446.2427-2-david@sigma-star.at> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: sigma-star.at; dkim=none (message not signed) header.d=none;sigma-star.at; dmarc=none action=none header.from=nxp.com; x-originating-ip: [192.88.146.1] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1;VI1PR0401MB2623;7:IdaWiRIVlG4K3CstNOXg8e2NycdzPBXfL+WnmiNmYj6PaZcADW7NX/+Qt+NOmmT5CjfZyft9Czq1exgX/7vSa2KSX/SesH9GM+o4GaLrq1ceGxguAaS4hasLWkzREQcRaGd/Fa83T/vAKukTEOmYjJ8++pTvk6bshj2opICo4COFdV9eTYG6MQVCk4MVvn+vs206pOD6xmiOpMvWgEFpGvEBjjiBj2O+d9SZxv01f5GG7hBr2wo+ABYkhttI7AxGjcJ0ZDiO/wUVCmgZkqiteLQ19Dd2SKmq6RRbhesnKKIsytxqwFa/3TGTZCnIz0RMqobUiakA6iZ+KiAS+JKtYmt6FPtO03DPZViJPa4oRJCxw1mJzHpJt3MkIKB3AgqmO8WO5/Y2eIzXefMhc+4171aUjvvUnDEd4f79kauyUjeFa5j9mWL13Ba8uFLUh3u0T2S55VZqm+bUBOAKNbZSRYLUijVkMc5bdisJPnLs4zkfqofUnLB1Qq1JsggWkzYfwCzkbBsx3tpdjrDwNGg5jsGdW1O6IHlMs1vz7bkkiOyZMPACWcSm21KO63an0HWFnC/riW+kSH94t+zEyEHaK4AZaSVYoPJIcKhS6/NMxitKT3wNBVZnWDQuvjWLaNGaMjzZ6Yc25+0DaVvKMBj8e0LgN09Q8EncNeOblJ5KPxlpyeouDl6Q9hvQoSYm3Ihe08HmQ9yNkYcGlXpf9rZpnb+XRDPS1mzE6E20aKaWImGtAytCila+7MpB1Ey1fcNEEzZFVboHuQwGDGPM/Cdr3hsh3te4kZrbK03b87AEx3k= x-forefront-antispam-report: SFV:SKI;SCL:-1SFV:NSPM;SFS:(10009020)(6009001)(39400400002)(39410400002)(39450400003)(39850400002)(39840400002)(39860400002)(377454003)(24454002)(7696004)(2906002)(3660700001)(229853002)(3280700002)(54356999)(50986999)(2201001)(76176999)(4326008)(5660300001)(7736002)(74316002)(305945005)(53546009)(25786009)(8676002)(81166006)(66066001)(6246003)(189998001)(2501003)(99286003)(53936002)(6436002)(14454004)(6506006)(86362001)(38730400002)(55016002)(54906002)(9686003)(2900100001)(8936002)(478600001)(33656002)(3846002)(102836003)(6116002)(142933001)(217873001);DIR:OUT;SFP:1101;SCL:1;SRVR:VI1PR0401MB2623;H:VI1PR0401MB2591.eurprd04.prod.outlook.com;FPR:;SPF:None;MLV:sfv;LANG:en; x-ms-office365-filtering-correlation-id: 3050c6c7-dac3-48cb-ee19-08d4b6fe57aa x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081);SRVR:VI1PR0401MB2623; x-ms-traffictypediagnostic: VI1PR0401MB2623: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(100000703101)(100105400095)(3002001)(93006095)(93001095)(6055026)(6041248)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123564025)(20161123558100)(20161123562025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095);SRVR:VI1PR0401MB2623;BCL:0;PCL:0;RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095);SRVR:VI1PR0401MB2623; x-forefront-prvs: 0343AC1D30 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-2" MIME-Version: 1.0 X-OriginatorOrg: nxp.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jun 2017 10:31:27.3669 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0401MB2623 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.home.local id v5JAVcuj000322 On 6/2/2017 3:25 PM, David Gstir wrote: > Certain cipher modes like CTS expect the IV (req->info) of > ablkcipher_request (or equivalently req->iv of skcipher_request) to > contain the last ciphertext block when the {en,de}crypt operation is done. > This is currently not the case for the CAAM driver which in turn breaks > e.g. cts(cbc(aes)) when the CAAM driver is enabled. > > This patch fixes the CAAM driver to properly set the IV after the > {en,de}crypt operation of ablkcipher finishes. > > Signed-off-by: David Gstir > --- > drivers/crypto/caam/caamalg.c | 26 ++++++++++++++++++++++++-- > 1 file changed, 24 insertions(+), 2 deletions(-) > > diff --git a/drivers/crypto/caam/caamalg.c b/drivers/crypto/caam/caamalg.c > index 398807d1b77e..d13c1aee4427 100644 > --- a/drivers/crypto/caam/caamalg.c > +++ b/drivers/crypto/caam/caamalg.c > @@ -882,10 +882,11 @@ static void ablkcipher_encrypt_done(struct device *jrdev, u32 *desc, u32 err, > { > struct ablkcipher_request *req = context; > struct ablkcipher_edesc *edesc; > -#ifdef DEBUG > struct crypto_ablkcipher *ablkcipher = crypto_ablkcipher_reqtfm(req); > int ivsize = crypto_ablkcipher_ivsize(ablkcipher); > + int nents; > > +#ifdef DEBUG > dev_err(jrdev, "%s %d: err 0x%x\n", __func__, __LINE__, err); > #endif > > @@ -904,6 +905,19 @@ static void ablkcipher_encrypt_done(struct device *jrdev, u32 *desc, u32 err, > #endif > > ablkcipher_unmap(jrdev, edesc, req); > + > + if (req->src == req->dst) > + nents = edesc->src_nents; > + else > + nents = edesc->dst_nents; > + > + /* > + * The crypto API expects us to set the IV (req->info) to the last > + * ciphertext block. This is used e.g. by the CTS mode. > + */ IIUC, IV update is required only in case of CBC. Since this callback is used also for CTR, we should avoid the copy: if ((ctx->cdata.algtype & OP_ALG_AAI_MASK) == OP_ALG_AAI_CBC) ... > + sg_pcopy_to_buffer(req->dst, nents, req->info, ivsize, > + req->nbytes - ivsize); scatterwalk_map_and_copy() should be used instead. > + > kfree(edesc); > > ablkcipher_request_complete(req, err); > @@ -914,10 +928,10 @@ static void ablkcipher_decrypt_done(struct device *jrdev, u32 *desc, u32 err, > { > struct ablkcipher_request *req = context; > struct ablkcipher_edesc *edesc; > -#ifdef DEBUG > struct crypto_ablkcipher *ablkcipher = crypto_ablkcipher_reqtfm(req); > int ivsize = crypto_ablkcipher_ivsize(ablkcipher); > > +#ifdef DEBUG > dev_err(jrdev, "%s %d: err 0x%x\n", __func__, __LINE__, err); > #endif > > @@ -935,6 +949,14 @@ static void ablkcipher_decrypt_done(struct device *jrdev, u32 *desc, u32 err, > #endif > > ablkcipher_unmap(jrdev, edesc, req); > + > + /* > + * The crypto API expects us to set the IV (req->info) to the last > + * ciphertext block. > + */ > + sg_pcopy_to_buffer(req->src, edesc->src_nents, req->info, ivsize, > + req->nbytes - ivsize); > + > kfree(edesc); > > ablkcipher_request_complete(req, err); >