Re: [PATCH v4 08/13] tpm: Add full HMAC and encrypt/decrypt session handling code

From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Jarkko Sakkinen <jarkko@kernel.org>, linux-integrity@vger.kernel.org
Cc: keyrings@vger.kernel.org, Ard Biesheuvel <ardb@kernel.org>,
	Mimi Zohar <zohar@linux.ibm.com>
Subject: Re: [PATCH v4 08/13] tpm: Add full HMAC and encrypt/decrypt session handling code
Date: Mon, 04 Dec 2023 07:35:54 -0500	[thread overview]
Message-ID: <987f9fc8e9e8df38e66e6d4a2fd1f8eb570899ff.camel@HansenPartnership.com> (raw)
In-Reply-To: <CXF71WGDHXAW.28FXYY08L1DMR@suppilovahvero>

On Mon, 2023-12-04 at 04:29 +0200, Jarkko Sakkinen wrote:
> On Sun Nov 26, 2023 at 5:05 PM EET, James Bottomley wrote:
> > On Sun, 2023-11-26 at 05:39 +0200, Jarkko Sakkinen wrote:
> > > One very obvious thing to fix there is the kconfig flag:
> > > 
> > > 1. Its meaning and purpose is not documented to the commit
> > > message. What is it and what is its meaning and purpose.
> > > 2. TPM_BUS_SECURITY does not follow the naming convention of
> > > other TPM kconfig flags, and to add, "security" is way way too
> > > abstract word. Something like TCG_TPM_HMAC
> > > 
> > >    It should be renamed as TCG_TPM_
> > 
> > One question is do we still need this?  Since my tree has moved
> > ahead, I also need the HMAC code for policy on keys and the primary
> > code for permanent parents.  The only real performance concern is
> > for PCR extension (no-one really cares about the speed of unseal or
> > random), so a different possible way of doing this is simply to
> > CONFIG that one operation.
> 
> I think so.
> 
> Major distributions have started to ship with TPM2 sealed hardware
> drive encryption, based on LVM/LUKS2 partitioning setup. It is
> convenient enough that at least I prefer it over encrypted
> passphrase.
> 
> Having this feature would add defence in depth to that. I could
> definitely see distributions adapting also to HMAC because now there
> is already too legit uses cases (ignoring the people who just enjoy
> configuring obscure things).
> 
> So motivation has rised by a factor now, i.e. it makes sense now more
> as a "product" and not just research topic, given the use in the
> workstation, in addition to the data center.

Sorry, miscommunication.  By "this" I meant the config option not the
entire HMAC code.  The proposal without it would be unconditionally
compile tpm2-sessions.c and do HMAC/encryption on random and
seal/unseal but gate the PCR HMAC via a compile or runtime option so as
not to degrade IMA performance if performance were preferable to
security.

James