All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ard Biesheuvel <ardb@kernel.org>
To: alsa-devel@alsa-project.org
Cc: Herbert Xu <herbert@gondor.apana.org.au>,
	Arnd Bergmann <arnd@arndb.de>,
	Liam Girdwood <lgirdwood@gmail.com>,
	Eric Biggers <ebiggers@kernel.org>,
	Guenter Roeck <groeck@chromium.org>,
	Mark Brown <broonie@kernel.org>,
	Enric Balletbo i Serra <enric.balletbo@collabora.com>,
	Benson Leung <bleung@chromium.org>,
	Ard Biesheuvel <ardb@kernel.org>,
	Cheng-Yi Chiang <cychiang@chromium.org>
Subject: [PATCH] SoC: cros_ec_codec: switch to library API for SHA-256
Date: Thu, 14 May 2020 18:18:47 +0200	[thread overview]
Message-ID: <20200514161847.6240-1-ardb@kernel.org> (raw)

The CrOS EC codec driver uses SHA-256 explicitly, and not in a
performance critical manner, so there is really no point in using
the dynamic SHASH crypto API here. Let's switch to the library API
instead.

Cc: Cheng-Yi Chiang <cychiang@chromium.org> 
Cc: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Cc: Guenter Roeck <groeck@chromium.org>
Cc: Benson Leung <bleung@chromium.org>
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Eric Biggers <ebiggers@kernel.org>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
---
Looking at the code, I was wondering if the SHA-256 is really required
here? It looks like it is using it as some kind of fingerprint to decide
whether the provided file is identical to the one that has already been
loaded. If this is the case, we should probably just use CRC32 instead.

Also, do we really need to wipe the context struct? Is there any security
sensitive data in there?

 sound/soc/codecs/Kconfig         |  3 +--
 sound/soc/codecs/cros_ec_codec.c | 21 +++++---------------
 2 files changed, 6 insertions(+), 18 deletions(-)

diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index e6a0c5d05fa5..c7ce4cc658cf 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -537,8 +537,7 @@ config SND_SOC_CQ0093VC
 config SND_SOC_CROS_EC_CODEC
 	tristate "codec driver for ChromeOS EC"
 	depends on CROS_EC
-	select CRYPTO
-	select CRYPTO_SHA256
+	select CRYPTO_LIB_SHA256
 	help
 	  If you say yes here you will get support for the
 	  ChromeOS Embedded Controller's Audio Codec.
diff --git a/sound/soc/codecs/cros_ec_codec.c b/sound/soc/codecs/cros_ec_codec.c
index d3dc42aa6825..6bc02c485ab2 100644
--- a/sound/soc/codecs/cros_ec_codec.c
+++ b/sound/soc/codecs/cros_ec_codec.c
@@ -107,24 +107,13 @@ static int send_ec_host_command(struct cros_ec_device *ec_dev, uint32_t cmd,
 static int calculate_sha256(struct cros_ec_codec_priv *priv,
 			    uint8_t *buf, uint32_t size, uint8_t *digest)
 {
-	struct crypto_shash *tfm;
+	struct sha256_state sctx;
 
-	tfm = crypto_alloc_shash("sha256", CRYPTO_ALG_TYPE_SHASH, 0);
-	if (IS_ERR(tfm)) {
-		dev_err(priv->dev, "can't alloc shash\n");
-		return PTR_ERR(tfm);
-	}
-
-	{
-		SHASH_DESC_ON_STACK(desc, tfm);
-
-		desc->tfm = tfm;
-
-		crypto_shash_digest(desc, buf, size, digest);
-		shash_desc_zero(desc);
-	}
+	sha256_init(&sctx);
+	sha256_update(&sctx, buf, size);
+	sha256_final(&sctx, digest);
 
-	crypto_free_shash(tfm);
+	memzero_explicit(&sctx, sizeof(sctx));
 
 #ifdef DEBUG
 	{
-- 
2.17.1


             reply	other threads:[~2020-05-15  5:59 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-14 16:18 Ard Biesheuvel [this message]
2020-05-14 16:25 ` [PATCH] SoC: cros_ec_codec: switch to library API for SHA-256 Benson Leung
2020-05-15  2:40   ` Tzung-Bi Shih
2020-05-15  6:04     ` Ard Biesheuvel
2020-05-15  6:40       ` Tzung-Bi Shih
2020-05-15  6:48         ` Tzung-Bi Shih
2020-05-15  6:50         ` Ard Biesheuvel
2020-05-15  9:02           ` Tzung-Bi Shih
2020-05-15  9:08             ` Ard Biesheuvel
2020-05-15  9:47 ` Mark Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200514161847.6240-1-ardb@kernel.org \
    --to=ardb@kernel.org \
    --cc=alsa-devel@alsa-project.org \
    --cc=arnd@arndb.de \
    --cc=bleung@chromium.org \
    --cc=broonie@kernel.org \
    --cc=cychiang@chromium.org \
    --cc=ebiggers@kernel.org \
    --cc=enric.balletbo@collabora.com \
    --cc=groeck@chromium.org \
    --cc=herbert@gondor.apana.org.au \
    --cc=lgirdwood@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.