From nobody Sun Oct 5 16:14:43 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 738F328DB73; Fri, 1 Aug 2025 21:26:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1754083579; cv=none; b=Fv41IdACoMQRcneN8x93hgc1Aa0gYR/SzIAUU5UfiARapfZbtiCTyIrm8uwEH4h3mhSbIyjbDRZzAXnk4ZoxUL5gIrtV3hCXw/gCwGeR7cgb/vJnVsENkLvP5vtBVzYFKgt0IDVIkdQAlPKD5jwUrhe75caX7O/67zp23U7c2fY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1754083579; c=relaxed/simple; bh=HZz9PkWbnw0uEcgraqNFNb8Xwl9CJAZ11ClEKIyhBfA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=TD/pg1WuWYFnLM/JBBUfFX71Va9V3wK2ggHdIizZcXHHXTvaQ5xe99AigkW9hmOaDtzyqD4UA8xzhdw7JlkNhFIYAeJmucI3QBGEA2RxpcEz3fHypZpUD5GMez66zvfajaus+iNQTYR+4upSfHefrei4GlDAn09B0fsakMN49lE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=gjc5EfQL; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="gjc5EfQL" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B669FC4CEF9; Fri, 1 Aug 2025 21:26:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1754083579; bh=HZz9PkWbnw0uEcgraqNFNb8Xwl9CJAZ11ClEKIyhBfA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=gjc5EfQLF0Lavcpd6bo993onkSQIShmF9OxdhcwMeqioCFxuTRm6y+pbF0bsUG5Wp T+0ud3y4ui4iGXbVv1xuE4T6bUJ+G/XGScyMp886tqvEVHPa4FUvgwfhXga75cajkv ektCer2lWM+hW6rDYiPNWc8Ykb1sT/hbPbUxw5WmtGZMGfAhAcgxOUfdIdRxSVaUqf SPYg9w8beB39av38Hwxcvb/HEZGCpqd39miKSg210BcnYvXzfe13LhJK3TPWsEz5us XiCNVHtCeFxRHkJ8wptJQWCHv541Khr4YKgD8DlJ2gaKs//7fKYWd9UriyZrel9LOW a4uih01XtwRzg== From: Eric Biggers To: Peter Huewe , Jarkko Sakkinen , linux-integrity@vger.kernel.org Cc: Jason Gunthorpe , James Bottomley , linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org, Eric Biggers Subject: [PATCH v2 1/2] tpm: Compare HMAC values in constant time Date: Fri, 1 Aug 2025 14:24:21 -0700 Message-ID: <20250801212422.9590-2-ebiggers@kernel.org> X-Mailer: git-send-email 2.50.1 In-Reply-To: <20250801212422.9590-1-ebiggers@kernel.org> References: <20250801212422.9590-1-ebiggers@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" 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 --- 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-sessi= ons.c index bdb119453dfbe..5fbd62ee50903 100644 --- a/drivers/char/tpm/tpm2-sessions.c +++ b/drivers/char/tpm/tpm2-sessions.c @@ -69,10 +69,11 @@ #include #include #include #include #include +#include =20 /* maximum number of names the TPM must remember for authorization */ #define AUTH_MAX_NAMES 3 =20 #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) =3D=3D 0) { - rc =3D 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 =3D 0; =20 /* now do response decryption */ if (auth->attrs & TPM2_SA_ENCRYPT) { /* need key and IV */ tpm2_KDFa(auth->session_key, SHA256_DIGEST_SIZE --=20 2.50.1