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;
From:   Pascal Van Leeuwen <pvanleeuwen@verimatrix.com>
To:     Arnd Bergmann <arnd@arndb.de>,
        Antoine Tenart <antoine.tenart@bootlin.com>,
        Herbert Xu <herbert@gondor.apana.org.au>,
        "David S. Miller" <davem@davemloft.net>
CC:     Pascal van Leeuwen <pascalvanl@gmail.com>,
        Ard Biesheuvel <ard.biesheuvel@linaro.org>,
        Eric Biggers <ebiggers@google.com>,
        "linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH 2/3] crypto: inside-secure - Reduce stack usage
Thread-Topic: [PATCH 2/3] crypto: inside-secure - Reduce stack usage
Thread-Index: AQHVd4jLpZQEIOemw0ukUdKdGUz6fqdEkO9A
Date:   Mon, 30 Sep 2019 19:04:23 +0000
Message-ID: <CH2PR20MB2968B7855D241C747BEB68B9CA820@CH2PR20MB2968.namprd20.prod.outlook.com>
References: <20190930121520.1388317-1-arnd@arndb.de>
 <20190930121520.1388317-2-arnd@arndb.de>
In-Reply-To: <20190930121520.1388317-2-arnd@arndb.de>
Accept-Language: en-US
Content-Language: en-US
received-spf: None (protection.outlook.com: verimatrix.com does not designate
 permitted sender hosts)
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: fbdcd030-0bf0-4ec9-c0bb-08d745d901cb
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Sep 2019 19:04:23.5635
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: dcb260f9-022d-4495-8602-eae51035a0d0
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: EIua5YWqSTkQw1wXlQq9MRxCvR6PggX22phHAxZS+4XZjUng9HT2lLTMOYe13Rnh9ir3nQS/9YD9GNwPrWIZxhArqu3ru2MIngxI+NB8THg=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2SPR01MB0005
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

> -----Original Message-----
> From: Arnd Bergmann <arnd@arndb.de>
> Sent: Monday, September 30, 2019 2:15 PM
> To: Antoine Tenart <antoine.tenart@bootlin.com>; Herbert Xu <herbert@gond=
or.apana.org.au>;
> David S. Miller <davem@davemloft.net>
> Cc: Arnd Bergmann <arnd@arndb.de>; Pascal Van Leeuwen <pvanleeuwen@verima=
trix.com>; Pascal
> van Leeuwen <pascalvanl@gmail.com>; Ard Biesheuvel <ard.biesheuvel@linaro=
.org>; Eric Biggers
> <ebiggers@google.com>; linux-crypto@vger.kernel.org; linux-kernel@vger.ke=
rnel.org
> Subject: [PATCH 2/3] crypto: inside-secure - Reduce stack usage
>=20
> safexcel_aead_setkey() contains three large stack variables, totalling
> slightly more than the 1024 byte warning limit:
>=20
> drivers/crypto/inside-secure/safexcel_cipher.c:303:12: error: stack frame=
 size of 1032 bytes
> in function 'safexcel_aead_setkey' [-Werror,-Wframe-larger-than=3D]
>=20
Ok, I did not realise that, so thanks for pointing that out to me.

> The function already contains a couple of dynamic allocations, so it is
> likely not performance critical and it can only be called in a context
> that allows sleeping, so the easiest workaround is to add change it
> to use dynamic allocations. Combining istate and ostate into a single
> variable simplifies the allocation at the cost of making it slightly
> less readable.
>=20
Hmmm... I wouldn't exactly consider it to be not performance critical - it
can be under certain circumstanced, but I guess it's already wasting lots
of cycles on allocations and key precomputes in safexcel_hmac_setkey, so
for now dynamically allocating the state is fine.

> Alternatively, it should be possible to shrink these allocations
> as the extra buffers appear to be largely unnecessary, but doing
> this would be a much more invasive change.
>=20
Actually, for HMAC-SHA512 you DO need all that buffer space.
You could shrink it to 2 * ctx->state_sz but then your simple indexing
is no longer going to fly. Not sure if that would be worth the effort.

I don't like the part where you dynamically allocate the cryto_aes_ctx
though, I think that was not necessary considering its a lot smaller.
And it conflicts with another change I have waiting that gets rid of=20
aes_expandkey and that struct alltogether (since it was really just
abused to do a key size check, which was very wasteful since the=20
function actually generates all roundkeys we don't need at all ...)

So I'll get rid of that struct anyway and doing it in this patch just
complicates applying your patch to my code or rebasing my stuff later.

> Fixes: 0e17e3621a28 ("crypto: inside-secure - add support for
> authenc(hmac(sha*),rfc3686(ctr(aes))) suites")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
>  .../crypto/inside-secure/safexcel_cipher.c    | 53 ++++++++++++-------
>  1 file changed, 35 insertions(+), 18 deletions(-)
>=20
> diff --git a/drivers/crypto/inside-secure/safexcel_cipher.c b/drivers/cry=
pto/inside-
> secure/safexcel_cipher.c
> index ef51f8c2b473..51a4112aa9bc 100644
> --- a/drivers/crypto/inside-secure/safexcel_cipher.c
> +++ b/drivers/crypto/inside-secure/safexcel_cipher.c
> @@ -305,10 +305,10 @@ static int safexcel_aead_setkey(struct crypto_aead =
*ctfm, const u8
> *key,
>  {
>  	struct crypto_tfm *tfm =3D crypto_aead_tfm(ctfm);
>  	struct safexcel_cipher_ctx *ctx =3D crypto_tfm_ctx(tfm);
> -	struct safexcel_ahash_export_state istate, ostate;
> +	struct safexcel_ahash_export_state *state;
>  	struct safexcel_crypto_priv *priv =3D ctx->priv;
> +	struct crypto_aes_ctx *aes;
>  	struct crypto_authenc_keys keys;
> -	struct crypto_aes_ctx aes;
>  	int err =3D -EINVAL;
>=20
>  	if (crypto_authenc_extractkeys(&keys, key, len) !=3D 0)
> @@ -334,7 +334,14 @@ static int safexcel_aead_setkey(struct crypto_aead *=
ctfm, const u8 *key,
>  			goto badkey_expflags;
>  		break;
>  	case SAFEXCEL_AES:
> -		err =3D aes_expandkey(&aes, keys.enckey, keys.enckeylen);
> +		aes =3D kzalloc(sizeof(*aes), GFP_KERNEL);
> +		if (!aes) {
> +			err =3D -ENOMEM;
> +			goto badkey;
> +		}
> +
> +		err =3D aes_expandkey(aes, keys.enckey, keys.enckeylen);
> +		kfree(aes);
>  		if (unlikely(err))
>  			goto badkey;
>  		break;
> @@ -347,56 +354,66 @@ static int safexcel_aead_setkey(struct crypto_aead =
*ctfm, const u8
> *key,
>  	    memcmp(ctx->key, keys.enckey, keys.enckeylen))
>  		ctx->base.needs_inv =3D true;
>=20
> +	state =3D kzalloc(sizeof(struct safexcel_ahash_export_state) * 2, GFP_K=
ERNEL);
> +	if (!state) {
> +		err =3D -ENOMEM;
> +		goto badkey;
> +	}
> +
>  	/* Auth key */
>  	switch (ctx->hash_alg) {
>  	case CONTEXT_CONTROL_CRYPTO_ALG_SHA1:
>  		if (safexcel_hmac_setkey("safexcel-sha1", keys.authkey,
> -					 keys.authkeylen, &istate, &ostate))
> -			goto badkey;
> +					 keys.authkeylen, &state[0], &state[1]))
> +			goto badkey_free;
>  		break;
>  	case CONTEXT_CONTROL_CRYPTO_ALG_SHA224:
>  		if (safexcel_hmac_setkey("safexcel-sha224", keys.authkey,
> -					 keys.authkeylen, &istate, &ostate))
> -			goto badkey;
> +					 keys.authkeylen, &state[0], &state[1]))
> +			goto badkey_free;
>  		break;
>  	case CONTEXT_CONTROL_CRYPTO_ALG_SHA256:
>  		if (safexcel_hmac_setkey("safexcel-sha256", keys.authkey,
> -					 keys.authkeylen, &istate, &ostate))
> -			goto badkey;
> +					 keys.authkeylen, &state[0], &state[1]))
> +			goto badkey_free;
>  		break;
>  	case CONTEXT_CONTROL_CRYPTO_ALG_SHA384:
>  		if (safexcel_hmac_setkey("safexcel-sha384", keys.authkey,
> -					 keys.authkeylen, &istate, &ostate))
> -			goto badkey;
> +					 keys.authkeylen, &state[0], &state[1]))
> +			goto badkey_free;
>  		break;
>  	case CONTEXT_CONTROL_CRYPTO_ALG_SHA512:
>  		if (safexcel_hmac_setkey("safexcel-sha512", keys.authkey,
> -					 keys.authkeylen, &istate, &ostate))
> -			goto badkey;
> +					 keys.authkeylen, &state[0], &state[1]))
> +			goto badkey_free;
>  		break;
>  	default:
>  		dev_err(priv->dev, "aead: unsupported hash algorithm\n");
> -		goto badkey;
> +		goto badkey_free;
>  	}
>=20
>  	crypto_aead_set_flags(ctfm, crypto_aead_get_flags(ctfm) &
>  				    CRYPTO_TFM_RES_MASK);
>=20
>  	if (priv->flags & EIP197_TRC_CACHE && ctx->base.ctxr_dma &&
> -	    (memcmp(ctx->ipad, istate.state, ctx->state_sz) ||
> -	     memcmp(ctx->opad, ostate.state, ctx->state_sz)))
> +	    (memcmp(ctx->ipad, &state[0].state, ctx->state_sz) ||
> +	     memcmp(ctx->opad, &state[1].state, ctx->state_sz)))
>  		ctx->base.needs_inv =3D true;
>=20
>  	/* Now copy the keys into the context */
>  	memcpy(ctx->key, keys.enckey, keys.enckeylen);
>  	ctx->key_len =3D keys.enckeylen;
>=20
> -	memcpy(ctx->ipad, &istate.state, ctx->state_sz);
> -	memcpy(ctx->opad, &ostate.state, ctx->state_sz);
> +	memcpy(ctx->ipad, &state[0].state, ctx->state_sz);
> +	memcpy(ctx->opad, &state[1].state, ctx->state_sz);
>=20
>  	memzero_explicit(&keys, sizeof(keys));
> +	kfree(state);
> +
>  	return 0;
>=20
> +badkey_free:
> +	kfree(state);
>  badkey:
>  	crypto_aead_set_flags(ctfm, CRYPTO_TFM_RES_BAD_KEY_LEN);
>  badkey_expflags:
> --
> 2.20.0

Regards,
Pascal van Leeuwen
Silicon IP Architect, Multi-Protocol Engines @ Verimatrix
www.insidesecure.com