public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Jarkko Sakkinen" <jarkko@kernel.org>
To: "Mimi Zohar" <zohar@linux.ibm.com>, <linux-integrity@vger.kernel.org>
Cc: <James.Bottomley@HansenPartnership.com>,
	<roberto.sassu@huawei.com>, <mapengyu@gmail.com>,
	"Paul Moore" <paul@paul-moore.com>,
	<linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH] tpm: Allow the TPM2 pcr_extend HMAC capability to be disabled on boot
Date: Wed, 16 Oct 2024 00:29:48 +0300	[thread overview]
Message-ID: <D4WP74KE8VZF.3VJITHXKVZOHK@kernel.org> (raw)
In-Reply-To: <20241015193916.59964-1-zohar@linux.ibm.com>

On Tue Oct 15, 2024 at 10:39 PM EEST, Mimi Zohar wrote:
> The initial TPM2 HMAC session capability added HMAC authentication to
> each and every TPM communication making the pcr_extend performance
> abysmal for HW TPMs. Further, the new CONFIG_TCG_TPM2_HMAC option was
> configured by default on x86_64.
>
> The decision to use the TPM2 HMAC session capability feature doesn't
> differentiate between the critical encrypted and the non-encrypted
> communication, but when configured is required for all TPM communication.
>
> In addition, the reason to HMAC the tpm2_pcr_extend() as provided in commit
> 6519fea6fd37 ("tpm: add hmac checks to tpm2_pcr_extend()") was to protect
> tpm2_pcr_extend() when used by "trusted keys" to lock the PCR.  However,
> locking the PCR is currently limited to TPM 1.2.
>
> We can revert the commit which adds the HMAC sessions for
> tpm2_pcr_extend, allow just the TPM2 pcr_extend HMAC capability to be
> disabled on boot for better IMA performance, or define a generic boot
> command line option to disable HMAC in general.  This patch allows
> disabling the HMAC for just the TPM2_pcr_extend.
>
> Fixes: 6519fea6fd37 ("tpm: add hmac checks to tpm2_pcr_extend()")
> Co-developed-by: Roberto Sassu <roberto.sassu@huawei.com>
> Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com>
> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
> ---
> Comment: applied and tested with/without patches in Jarkko's hmac-v5 branch -
> commit 92999f9cd11f ("tpm: flush the auth session only when /dev/tpm0 is open")
>
>  .../admin-guide/kernel-parameters.txt         |  5 ++
>  drivers/char/tpm/tpm2-cmd.c                   | 41 ++++++++++---
>  drivers/char/tpm/tpm2-sessions.c              | 59 +++++++++++--------
>  include/linux/tpm.h                           |  4 ++
>  4 files changed, 77 insertions(+), 32 deletions(-)
>
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index 1518343bbe22..c7811f32ba28 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -6727,6 +6727,11 @@
>  	torture.verbose_sleep_duration= [KNL]
>  			Duration of each verbose-printk() sleep in jiffies.
>  
> +	tpm_pcr_extend_hmac_disable [HW,TPM]
> +			Disable TPM2 pcr_extend HMAC for better IMA
> +			performance. By default is set to true (1).
> +			Mainly needed when using a HW TPM2.

Thanks for doing this! I think the code change itself is pretty good but
maybe we should not emphasize HMAC per se (applies to config flag too but
it is what it is now) but instead that they are encrypted and integrity
protected.

I guess all these features intend to protect data from unintended and
physical access, like in common sense terms.

So like for any possible sysadmin and similar I think this would be something
that anyone could grab:

	tpm_disable_protect_pcrs [HW,TPM]
			Do not protect PCR registers from unintended physical
			access, or interposers in the bus by the means of
			having an encrypted and integrity protected session 
			wrapped around TPM2_PCR_Extend command. Consider this
			in a situation where TPM is heavily utilized by
			IMA, thus protection causing a major performance hit,
			and the space where machines are deployed is by other
			means guarded.

Perhaps a bit long but at least it is clear and helps to make the right choice.

BR, Jarkko

  reply	other threads:[~2024-10-15 21:29 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-15 19:39 [RFC PATCH] tpm: Allow the TPM2 pcr_extend HMAC capability to be disabled on boot Mimi Zohar
2024-10-15 21:29 ` Jarkko Sakkinen [this message]
2024-10-15 21:46   ` Jarkko Sakkinen
2024-11-06 22:26 ` Jarkko Sakkinen
2024-11-06 22:52   ` James Bottomley
2024-11-06 23:22     ` Jarkko Sakkinen
2024-11-06 23:40       ` Jarkko Sakkinen
2024-11-06 23:42         ` Jarkko Sakkinen
2024-11-06 23:52       ` Mimi Zohar
2024-11-07  0:03         ` Jarkko Sakkinen
2024-11-07  1:07           ` Mimi Zohar
2024-11-07  1:55             ` Jarkko Sakkinen
2024-11-07  3:14               ` Mimi Zohar
2024-11-07  6:32                 ` 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=D4WP74KE8VZF.3VJITHXKVZOHK@kernel.org \
    --to=jarkko@kernel.org \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mapengyu@gmail.com \
    --cc=paul@paul-moore.com \
    --cc=roberto.sassu@huawei.com \
    --cc=zohar@linux.ibm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox