From:   Horia Geanta <horia.geanta@nxp.com>
To:     Sascha Hauer <s.hauer@pengutronix.de>
CC:     "linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
        Herbert Xu <herbert@gondor.apana.org.au>,
        "kernel@pengutronix.de" <kernel@pengutronix.de>,
        "stable@vger.kernel.org" <stable@vger.kernel.org>
Subject: Re: [PATCH] crypto: caam - Do not overwrite IV
Thread-Topic: [PATCH] crypto: caam - Do not overwrite IV
Thread-Index: AQHUuSvyCmTFYLEeOE2P2XtmnR+/Zg==
Date:   Tue, 5 Feb 2019 11:49:52 +0000
Message-ID: <VI1PR0402MB34852118C52B0A0CB409A8F6986E0@VI1PR0402MB3485.eurprd04.prod.outlook.com>
References: <20190131061225.15541-1-s.hauer@pengutronix.de>
 <VI1PR0402MB3485ED41FE4B512C83271E0B986D0@VI1PR0402MB3485.eurprd04.prod.outlook.com>
 <20190205083146.icnk3y46vonpxsin@pengutronix.de>
Accept-Language: en-US
Content-Language: en-US
received-spf: None (protection.outlook.com: nxp.com does not designate
 permitted sender hosts)
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 1b700e07-daeb-4666-43ae-08d68b600a9d
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Feb 2019 11:49:52.9793
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0402MB3392
Sender: linux-crypto-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-crypto.vger.kernel.org>
X-Mailing-List: linux-crypto@vger.kernel.org

On 2/5/2019 10:31 AM, Sascha Hauer wrote:=0A=
> Hi Horia,=0A=
> =0A=
> On Mon, Feb 04, 2019 at 12:26:26PM +0000, Horia Geanta wrote:=0A=
>> On 1/31/2019 8:12 AM, Sascha Hauer wrote:=0A=
>>> In skcipher_decrypt() the IV passed in by the caller is overwritten and=
=0A=
>>> the tcrypt module fails with:=0A=
>>>=0A=
>>> alg: aead: decryption failed on test 1 for gcm_base(ctr-aes-caam,ghash-=
generic): ret=3D74=0A=
>>> alg: aead: Failed to load transform for gcm(aes): -2=0A=
>>>=0A=
>>> With this patch tcrypt runs without errors.=0A=
>>>=0A=
>> This doesn't mean the patch is correct.=0A=
>> crypto API requires skcipher implementations to update the IV with the l=
ast=0A=
>> ciphertext block.=0A=
>>=0A=
>> The root cause of the issue is cache line sharing.=0A=
>>=0A=
>> struct crypto_gcm_req_priv_ctx {=0A=
>>         u8 iv[16];=0A=
>>         u8 auth_tag[16];=0A=
>> 	[...]=0A=
>> };=0A=
>>=0A=
>> Since caam does not support ghash on i.MX6, only ctr skcipher part of th=
e gcm is=0A=
>> offloaded.=0A=
>> The skcipher request received by caam has req->src pointing to auth_tag[=
16] (1st=0A=
>> S/G entry) and req->iv pointing to iv[16].=0A=
>> caam driver:=0A=
>> 1-DMA maps req->src=0A=
>> 2-copies original req->iv to internal buffer=0A=
>> 3-updates req->iv (scatterwalk_map_and_copy from last block in req->src)=
=0A=
>> 4-sends job to crypto engine=0A=
>>=0A=
>> Problem is that operation 3 above is writing iv[16], which is on the sam=
e cache=0A=
>> line as auth_tag[16] that was previously DMA mapped.=0A=
>>=0A=
>> I've checked that forcing auth_tag and iv to be on separate cache lines=
=0A=
>> -       u8 auth_tag[16];=0A=
>> +       u8 auth_tag[16] ____cacheline_aligned;=0A=
>> solves the issue.=0A=
> =0A=
> I can confirm that this solves it here on my side aswell.=0A=
> =0A=
Thanks for confirming.=0A=
=0A=
> I have no idea what's best to do here, but I'd like to have that fixed.=
=0A=
> =0A=
Yes, me too.=0A=
I would wait for Herbert's input though. As I said, it's a bit weird for a=
=0A=
skcipher implementation to be aware of updating req->iv having such a side=
=0A=
effect on req->src.=0A=
=0A=
> Is there some easy to reproduce testcase to show the issues that arise=0A=
> with my patch? Apparently tcrypt doesn't do chaining, right?=0A=
> =0A=
In theory cts(cbc(aes)) decryption would have to fail when cbc(aes) would=
=0A=
execute on caam and cts() in SW.=0A=
=0A=
However, cts() SW implementation (crypto/cts.c) does not rely on underlying=
=0A=
cbc(aes) to update the IV, instead it uses a temporary saved IV - see discu=
ssion=0A=
here:=0A=
https://www.mail-archive.com/linux-crypto@vger.kernel.org/msg27719.html=0A=
=0A=
Horia=0A=
=0A=