All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jarkko Sakkinen <jarkko@kernel.org>
To: Eric Biggers <ebiggers@kernel.org>
Cc: Peter Huewe <peterhuewe@gmx.de>,
	linux-integrity@vger.kernel.org, Jason Gunthorpe <jgg@ziepe.ca>,
	James Bottomley <James.Bottomley@hansenpartnership.com>,
	linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/2] tpm: Compare HMAC values in constant time
Date: Tue, 5 Aug 2025 16:50:17 +0300	[thread overview]
Message-ID: <aJIMGWFDZejNwAVP@kernel.org> (raw)
In-Reply-To: <20250801212422.9590-2-ebiggers@kernel.org>

On Fri, Aug 01, 2025 at 02:24:21PM -0700, Eric Biggers wrote:
> In tpm_buf_check_hmac_response(), compare the HMAC values in constant
> time using crypto_memneq() instead of in variable time using memcmp().
> 
> This is worthwhile to follow best practices and to be consistent with
> MAC comparisons elsewhere in the kernel.  However, in this driver the
> side channel seems to have been benign: the HMAC input data is
> guaranteed to always be unique, which makes the usual MAC forgery via
> timing side channel not possible.  Specifically, the HMAC input data in
> tpm_buf_check_hmac_response() includes the "our_nonce" field, which was
> generated by the kernel earlier, remains under the control of the
> kernel, and is unique for each call to tpm_buf_check_hmac_response().
> 
> Signed-off-by: Eric Biggers <ebiggers@kernel.org>
> ---
>  drivers/char/tpm/Kconfig         | 1 +
>  drivers/char/tpm/tpm2-sessions.c | 6 +++---
>  2 files changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/char/tpm/Kconfig b/drivers/char/tpm/Kconfig
> index dddd702b2454a..f9d8a4e966867 100644
> --- a/drivers/char/tpm/Kconfig
> +++ b/drivers/char/tpm/Kconfig
> @@ -31,10 +31,11 @@ config TCG_TPM2_HMAC
>  	bool "Use HMAC and encrypted transactions on the TPM bus"
>  	default X86_64
>  	select CRYPTO_ECDH
>  	select CRYPTO_LIB_AESCFB
>  	select CRYPTO_LIB_SHA256
> +	select CRYPTO_LIB_UTILS
>  	help
>  	  Setting this causes us to deploy a scheme which uses request
>  	  and response HMACs in addition to encryption for
>  	  communicating with the TPM to prevent or detect bus snooping
>  	  and interposer attacks (see tpm-security.rst).  Saying Y
> diff --git a/drivers/char/tpm/tpm2-sessions.c b/drivers/char/tpm/tpm2-sessions.c
> index bdb119453dfbe..5fbd62ee50903 100644
> --- a/drivers/char/tpm/tpm2-sessions.c
> +++ b/drivers/char/tpm/tpm2-sessions.c
> @@ -69,10 +69,11 @@
>  #include <linux/unaligned.h>
>  #include <crypto/kpp.h>
>  #include <crypto/ecdh.h>
>  #include <crypto/hash.h>
>  #include <crypto/hmac.h>
> +#include <crypto/utils.h>
>  
>  /* maximum number of names the TPM must remember for authorization */
>  #define AUTH_MAX_NAMES	3
>  
>  #define AES_KEY_BYTES	AES_KEYSIZE_128
> @@ -827,16 +828,15 @@ int tpm_buf_check_hmac_response(struct tpm_chip *chip, struct tpm_buf *buf,
>  	sha256_update(&sctx, auth->our_nonce, sizeof(auth->our_nonce));
>  	sha256_update(&sctx, &auth->attrs, 1);
>  	/* we're done with the rphash, so put our idea of the hmac there */
>  	tpm2_hmac_final(&sctx, auth->session_key, sizeof(auth->session_key)
>  			+ auth->passphrase_len, rphash);
> -	if (memcmp(rphash, &buf->data[offset_s], SHA256_DIGEST_SIZE) == 0) {
> -		rc = 0;
> -	} else {
> +	if (crypto_memneq(rphash, &buf->data[offset_s], SHA256_DIGEST_SIZE)) {
>  		dev_err(&chip->dev, "TPM: HMAC check failed\n");
>  		goto out;
>  	}
> +	rc = 0;
>  
>  	/* now do response decryption */
>  	if (auth->attrs & TPM2_SA_ENCRYPT) {
>  		/* need key and IV */
>  		tpm2_KDFa(auth->session_key, SHA256_DIGEST_SIZE
> -- 
> 2.50.1
> 

I think we might want to also backport this to stables.

BR, Jarkko

  reply	other threads:[~2025-08-05 13:50 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-01 21:24 [PATCH v2 0/2] tpm: Clean up HMAC validation and computation Eric Biggers
2025-08-01 21:24 ` [PATCH v2 1/2] tpm: Compare HMAC values in constant time Eric Biggers
2025-08-05 13:50   ` Jarkko Sakkinen [this message]
2025-08-05 16:07     ` Eric Biggers
2025-08-09 10:36       ` Jarkko Sakkinen
2025-08-09 17:38         ` Eric Biggers
2025-09-04  2:38           ` Eric Biggers
2025-09-10 17:10             ` Jarkko Sakkinen
2025-08-01 21:24 ` [PATCH v2 2/2] tpm: Use HMAC-SHA256 library instead of open-coded HMAC Eric Biggers
2025-08-05 13:51   ` Jarkko Sakkinen

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=aJIMGWFDZejNwAVP@kernel.org \
    --to=jarkko@kernel.org \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=ebiggers@kernel.org \
    --cc=jgg@ziepe.ca \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterhuewe@gmx.de \
    /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.