linux-kernel - Re: [PATCH v4 3/5] crypto: tegra: Add Tegra Security Engine driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Fri, 2 Feb 2024 17:44:12 +0800
From: Herbert Xu <herbert@...dor.apana.org.au>
To: Akhil R <akhilrajeev@...dia.com>
Cc: davem@...emloft.net, robh+dt@...nel.org,
	krzysztof.kozlowski+dt@...aro.org, conor+dt@...nel.org,
	thierry.reding@...il.com, jonathanh@...dia.com,
	catalin.marinas@....com, will@...nel.org, mperttunen@...dia.com,
	linux-crypto@...r.kernel.org, devicetree@...r.kernel.org,
	linux-tegra@...r.kernel.org, linux-kernel@...r.kernel.org,
	krzk@...nel.org
Subject: Re: [PATCH v4 3/5] crypto: tegra: Add Tegra Security Engine driver

On Wed, Jan 24, 2024 at 02:08:44PM +0530, Akhil R wrote:
>
> +static void tegra_sha_init_fallback(struct tegra_sha_ctx *ctx, const char *algname)
> +{
> +	ctx->fallback_tfm = crypto_alloc_ahash(algname, 0, CRYPTO_ALG_ASYNC |
> +						CRYPTO_ALG_NEED_FALLBACK);
> +
> +	if (IS_ERR(ctx->fallback_tfm)) {
> +		dev_warn(ctx->se->dev, "failed to allocate fallback for %s %ld\n",
> +			 algname, PTR_ERR(ctx->fallback_tfm));
> +		ctx->fallback_tfm = NULL;
> +	}
> +}

This should check that the fallback state size is smaller than
that of tegra.  As otherwise the fallback export/import will break.

> +static int tegra_sha_import(struct ahash_request *req, const void *in)
> +{
> +	struct tegra_sha_reqctx *rctx = ahash_request_ctx(req);
> +	struct crypto_ahash *tfm = crypto_ahash_reqtfm(req);
> +	struct tegra_sha_ctx *ctx = crypto_ahash_ctx(tfm);
> +	int i;
> +
> +	if (ctx->fallback)
> +		return tegra_sha_fallback_import(req, in);
> +
> +	memcpy(rctx, in, sizeof(*rctx));
> +
> +	/* Paste all intermediate results */
> +	for (i = 0; i < HASH_RESULT_REG_COUNT; i++)
> +		writel(rctx->result[i],
> +		       ctx->se->base + ctx->se->hw->regs->result + (i * 4));

What happens when multiple requests of the same tfm import at
the same time?  Normally we don't actually touch the hardware
in the import function.  Instead, all the hard work happens at
the end of the update function, which moves hardware state into
the request object.

The import/export function then simply copies the request object
state to the in/out buffer.

Cheers,
-- 
Email: Herbert Xu <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt