All of lore.kernel.org
 help / color / mirror / Atom feed
From: Benson Leung <bleung@google.com>
To: Ard Biesheuvel <ardb@kernel.org>, tzungbi@google.com
Cc: alsa-devel@alsa-project.org,
	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>,
	Cheng-Yi Chiang <cychiang@chromium.org>
Subject: Re: [PATCH] SoC: cros_ec_codec: switch to library API for SHA-256
Date: Thu, 14 May 2020 09:25:48 -0700	[thread overview]
Message-ID: <20200514162548.GA141824@google.com> (raw)
In-Reply-To: <20200514161847.6240-1-ardb@kernel.org>

[-- Attachment #1: Type: text/plain, Size: 3264 bytes --]

Hi Ard,

On Thu, May 14, 2020 at 06:18:47PM +0200, Ard Biesheuvel wrote:
> 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?
> 

Adding Tzung-Bi Shih <tzungbi@google.com> to help answer these, as these
were added as a part of his change here:
 b6bc07d4360d  ASoC: cros_ec_codec: support WoV


Thanks,
Benson

>  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
> 

-- 
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
bleung@google.com
Chromium OS Project
bleung@chromium.org

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

  reply	other threads:[~2020-05-14 16:27 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-14 16:18 [PATCH] SoC: cros_ec_codec: switch to library API for SHA-256 Ard Biesheuvel
2020-05-14 16:25 ` Benson Leung [this message]
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=20200514162548.GA141824@google.com \
    --to=bleung@google.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=ardb@kernel.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 \
    --cc=tzungbi@google.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.