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

[Mimi Zohar <zohar@linux.ibm.com>]

On Mon, 2023-12-04 at 08:53 -0500, James Bottomley wrote:
> On Mon, 2023-12-04 at 08:43 -0500, Mimi Zohar wrote:
> > On Mon, 2023-12-04 at 07:35 -0500, James Bottomley wrote:
> > > 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.
> > 
> > Is there a way of not degrading IMA performance without disabling
> > HMAC encryption/decryption?
> 
> Well, perhaps we should measure it.  My operating assumption, since
> extend is a simple hash, is that most of the latency of extend is
> actually in the LPC (or i2c or whatever) bus round trip.  To do HMAC,
> you have to have a session, which adds an extra command and thus
> doubles the round trip.

Agreed getting some statistics would be beneficial.  Instead of
creating a session for each IMA extend, would it be possible to estable
a session once and re-use it?

Mimi