From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754688AbdIGKNG (ORCPT ); Thu, 7 Sep 2017 06:13:06 -0400 Received: from mail-he1eur01on0087.outbound.protection.outlook.com ([104.47.0.87]:46080 "EHLO EUR01-HE1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753927AbdIGKND (ORCPT ); Thu, 7 Sep 2017 06:13:03 -0400 From: =?iso-8859-2?Q?Horia_Geant=E3?= To: Gilad Ben-Yossef CC: David Gstir , Dan Douglass , "herbert@gondor.apana.org.au" , "davem@davemloft.net" , "richard@sigma-star.at" , "linux-crypto@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "stable@vger.kernel.org" Subject: Re: [PATCH] crypto: caam - properly set IV after {en,de}crypt Thread-Topic: [PATCH] crypto: caam - properly set IV after {en,de}crypt Thread-Index: AQHS8BJRT1JvsDHapk2P0fMxyxi4Kg== Date: Thu, 7 Sep 2017 10:12:56 +0000 Message-ID: References: <20170602122446.2427-1-david@sigma-star.at> <20170628132710.97278-1-david@sigma-star.at> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.88.146.1] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1;VI1PR0402MB3389;6:5o1wCv6gH7mKPGNnLPZ2fgSTvyNGhJH+Yczc2V4Ijgpq1Z4Vv4Ebp23UxOM5nC4XKEluId1uky2AzYmeoiJ3a+qkrfUvaxvYXfNjsRb58bHMQnTi/EP1tY1cPKyy4F+HYPe959dKiirqo9rFAUSyvhGm548qdwElp/B2KerdcUViOMHLwOaSTWcD0bTBoV+4aVw9Ct9GAo7p8ICQy1FfG8nAQzL905lMtNM6uAcMN6K4qhkHkkifWq/LydpcBP7HncZcQYoNSoYIwIO7B8U/5YcN6XIf4Qf2Uc6sXWTN/hroFw9kmRWvOvdhgOVKFkwnxiTcgWgQBsYg57BX0htw8A==;5:BPRdx8r69K0oxOW6WlyPYABMAPmOEIQWlhNDOpSK7xFaBAZa/dxzUdqDqYigYbV7wVeHdKKY9YLt5oLlCpVfOMhHf09sdxyLD7Z4KzJPDQX+0Null2pvrfD1vKP96rS/9HHQhmNYcotIf1GB9xsyGQ==;24:ZLJ4WBB5SbLpJGU4xRpyi0bAn02Sj/9yMKp01rL2mygoZ/5YA8o+HhogZKFK7c1qT0AV5zQc4n0VA/fT23lRhWu6Lujyj9AUCotiYF29Q74=;7:HMNAvquSREk7OCg8Q3F4Im+nhwApvq0++fkkyqcsdiX29HG0n4mezNeqvFGdPT60M1yRPKezuk0Ju0LPC4vDoQ7ZHZuErSqVNZieinFwzZG+TnTR3HoHITRTgBEty2rpSqnY5iGEkgn9hX0Q4s5yKmCy2WjK0qFjpr/hcUKPAYHzLQolfamlABiqrnkASJU9aFHNZfneCKuoymaogDMnhQkh+aNBwVtZMF/SQZmfhiE= x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR; x-forefront-antispam-report: SFV:SKI;SCL:-1;SFV:NSPM;SFS:(10009020)(6009001)(39860400002)(199003)(377454003)(24454002)(189002)(4326008)(101416001)(14454004)(25786009)(53546010)(478600001)(8936002)(33656002)(81156014)(68736007)(8676002)(106356001)(2900100001)(229853002)(189998001)(81166006)(50986999)(6436002)(6506006)(54356999)(76176999)(6916009)(105586002)(9686003)(3846002)(7736002)(102836003)(53936002)(5660300001)(93886005)(97736004)(2906002)(6116002)(86362001)(55016002)(74316002)(305945005)(54906002)(3280700002)(3660700001)(99286003)(5250100002)(110136004)(66066001)(6246003)(7696004)(142933001);DIR:OUT;SFP:1101;SCL:1;SRVR:VI1PR0402MB3389;H:VI1PR0402MB3342.eurprd04.prod.outlook.com;FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:en; x-ms-office365-filtering-correlation-id: 63cbbc9e-1933-45f2-088a-08d4f5d90278 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095);SRVR:VI1PR0402MB3389; x-ms-traffictypediagnostic: VI1PR0402MB3389: authentication-results: spf=none (sender IP is ) smtp.mailfrom=horia.geanta@nxp.com; x-exchange-antispam-report-test: UriScan:(9452136761055)(185117386973197); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(3002001)(6055026)(6041248)(20161123555025)(20161123560025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095);SRVR:VI1PR0402MB3389;BCL:0;PCL:0;RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095);SRVR:VI1PR0402MB3389; x-forefront-prvs: 04238CD941 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: 07 Sep 2017 10:12:56.2805 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0402MB3389 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 nfs id v87ADGpr017365 On 9/6/2017 1:14 PM, Gilad Ben-Yossef wrote: > On Tue, Sep 5, 2017 at 6:33 PM, Horia Geantã wrote: >> On 8/14/2017 10:59 AM, Gilad Ben-Yossef wrote: >>> Hi, >>> >>> On Thu, Jun 29, 2017 at 1:19 PM, Horia Geantã wrote: >>>> On 6/28/2017 4:42 PM, Horia Geantã wrote: >>>>> On 6/28/2017 4:27 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. >>>>>> >>>>>> This issue was revealed by the changes in the SW CTS mode in commit >>>>>> 0605c41cc53ca ("crypto: cts - Convert to skcipher") >>>>>> >>>>>> Cc: # 4.8+ >>>>>> Signed-off-by: David Gstir >>>>> Reviewed-by: Horia Geantã >>>>> >>>> Btw, instead of updating the IV in SW, CAAM engine could be programmed >>>> to do it - by saving the Context Register of the AES accelerator. >>>> >>>> Unfortunately this would require changes in quite a few places: shared >>>> descriptor, HW S/G generation logic, IV dma (un)mapping and maybe others. >>>> >>>> So it's better to have this fix now (which, considering size, is >>>> appropriate for -stable) and later, if needed, offload IV updating in HW. >>>> >>> >>> My apologies for reviving this thread from the dead, but doesn't the patch fail >>> for in-place decryption since we are copying from req->dst after >>> the operation is done, and therefore it no longer contains the ciphertext? >>> >> You are right, thanks! Will follow up with a fix. >> Though cts(cbc(aes)) in particular is working, see below. >> >>> I'm asking since I ran into a similar issue in the ccree driver and thought >>> to deploy a similar fix but could not convince myself why this works. >>> >> IIUC cts(cbc(aes)) in-place decryption (with cbc(aes) offloaded to CAAM >> engine) works since SW implementation of cts, when performing the >> ciphertext stealing phase in cts_cbc_decrypt() does not use req->iv, but >> a previously value, saved before staring decryption in crypto_cts_decrypt(): >> >> if (cbc_blocks <= 1) >> memcpy(space, req->iv, bsize); >> else >> scatterwalk_map_and_copy(space, req->src, offset - 2 * bsize, >> bsize, 0); >> > > Is that not a performance bug in software CTS than? I mean all those > transformation > drivers doing that extra copy and possibly malloc and free to save the > data for the info > and than have the CTS implementation ignore that and do its own memory copy? > AFAICT, in case cbc_blocks > 1 cts saves the second from last full block, while underlying cbc subrequest saves the last full block. Horia