From:   Horia Geanta <horia.geanta@nxp.com>
To:     Herbert Xu <herbert@gondor.apana.org.au>
CC:     Roland Hieber <rhi@pengutronix.de>,
        Aymen Sghaier <aymen.sghaier@nxp.com>,
        "linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
        Jesper Nilsson <jesper.nilsson@axis.com>,
        Lars Persson <lars.persson@axis.com>,
        Christian Lamparter <chunkeey@gmail.com>,
        Roland Hieber <r.hieber@pengutronix.de>,
        "David S. Miller" <davem@davemloft.net>,
        "kernel@pengutronix.de" <kernel@pengutronix.de>
Subject: Re: [PATCH 2/2] crypto: caam - fix DMA mapping of stack memory
Thread-Topic: [PATCH 2/2] crypto: caam - fix DMA mapping of stack memory
Thread-Index: AQHUsmbwIdQhV/qgPk+dqH8znmHDkA==
Date:   Fri, 25 Jan 2019 14:26:27 +0000
Message-ID: <VI1PR0402MB34859DF7A32E650C9E2E1A34989B0@VI1PR0402MB3485.eurprd04.prod.outlook.com>
References: <20190122152651.1150-1-rhi@pengutronix.de>
 <VI1PR0402MB348525A6FEFD55F6896C9249989B0@VI1PR0402MB3485.eurprd04.prod.outlook.com>
 <20190125134756.5f5e2uxmwvtnc6bb@gondor.apana.org.au>
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: bcd2ed57-eb05-47fa-7453-08d682d117b1
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jan 2019 14:26:27.5222
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0402MB3503
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 1/25/2019 3:48 PM, Herbert Xu wrote:=0A=
> On Fri, Jan 25, 2019 at 12:43:21PM +0000, Horia Geanta wrote:=0A=
>>=0A=
>> Herbert, is there something we could do to avoid this?=0A=
> =0A=
> Async crypto requests cannot be allocated off the stack.  So=0A=
> whoever is doing this needs to stop.=0A=
> =0A=
IIUC, the crypto request is allocated in ima_calc_file_hash_atfm() using=0A=
ahash_request_alloc(), so this seems to be fine.=0A=
=0A=
However, further below the req->result pointer is set to a location on stac=
k:=0A=
out2:=0A=
	if (!rc) {=0A=
		ahash_request_set_crypt(req, NULL, hash->digest, 0);=0A=
=0A=
More exactly, the call sequence is:=0A=
ima_collect_measurement() -> ima_calc_file_hash() -> ima_calc_file_ahash() =
->=0A=
ima_calc_file_hash_atfm()=0A=
and "hash" is allocated on stack in ima_collect_measurement().=0A=
=0A=
Thus, it seems the problem lies in the fact that ahash_request structure de=
fines=0A=
the digest buffer as "u8 *result" - thus the memory area might not be DMAab=
le.=0A=
=0A=
Thanks,=0A=
Horia=0A=