TPM HMAC (really) bad performance

TPM HMAC (really) bad performance

[Roberto Sassu]

Hi all

when running the benchmark on my new component, the Integrity Digest
Cache, I ran into a serious performance issue.

The benchmark is extending a TPM PCR with 12313 entries of the IMA
measurement list, and calculating the time elapsed for the operation.

Without TPM HMAC: 102.8 seconds

With TPM HMAC: 1941.71 seconds


Do you have already an idea on how to improve the situation?

Thanks

Roberto

Re: TPM HMAC (really) bad performance

[James Bottomley]

On Fri, 2024-09-06 at 14:32 +0200, Roberto Sassu wrote:
> Hi all
> 
> when running the benchmark on my new component, the Integrity Digest
> Cache, I ran into a serious performance issue.
> 
> The benchmark is extending a TPM PCR with 12313 entries of the IMA
> measurement list, and calculating the time elapsed for the operation.
> 
> Without TPM HMAC: 102.8 seconds
> 
> With TPM HMAC: 1941.71 seconds

I did worry about this and kept asking if anyone could benchmark

https://lore.kernel.org/linux-integrity/bd814edddfeac7072ed4f29365ce6bac3d235562.camel@HansenPartnership.com/

> Do you have already an idea on how to improve the situation?

One theory was that we could context save the session instead and this
might be faster but would also require degapping in the resource
manager.

James

Re: TPM HMAC (really) bad performance

[Jarkko Sakkinen]

On Fri Sep 6, 2024 at 3:32 PM EEST, Roberto Sassu wrote:
> Hi all
>
> when running the benchmark on my new component, the Integrity Digest
> Cache, I ran into a serious performance issue.
>
> The benchmark is extending a TPM PCR with 12313 entries of the IMA
> measurement list, and calculating the time elapsed for the operation.
>
> Without TPM HMAC: 102.8 seconds
>
> With TPM HMAC: 1941.71 seconds
>
>
> Do you have already an idea on how to improve the situation?

Some missing details: CPU architecture and TPM chip type.

Would be possible to generate off-CPU flame graph?

For decent instructions:

https://www.singlestore.com/blog/linux-off-cpu-investigation/

You can do post-processing steps "offline" only capture step would
need to be done in-target.

>
> Thanks
>
> Roberto

BR, Jarkko

Re: TPM HMAC (really) bad performance

[Roberto Sassu]

On Fri, 2024-09-06 at 14:32 +0200, Roberto Sassu wrote:
> Hi all
> 
> when running the benchmark on my new component, the Integrity Digest
> Cache, I ran into a serious performance issue.
> 
> The benchmark is extending a TPM PCR with 12313 entries of the IMA
> measurement list, and calculating the time elapsed for the operation.
> 
> Without TPM HMAC: 102.8 seconds
> 
> With TPM HMAC: 1941.71 seconds

Jarkko patch set [1] improved the performance:

404.4 seconds


Still quite slow. We should consider not only the boot performance.
Depending on the use case, IMA can be used after boot and slow down
applications performance.

Thanks

Roberto


[1] https://lore.kernel.org/linux-integrity/20240921120811.1264985-1-jarkko@kernel.org/

Re: TPM HMAC (really) bad performance

[James Bottomley]

On Fri, 2024-09-27 at 15:53 +0200, Roberto Sassu wrote:
> On Fri, 2024-09-06 at 14:32 +0200, Roberto Sassu wrote:
> > Hi all
> > 
> > when running the benchmark on my new component, the Integrity
> > Digest
> > Cache, I ran into a serious performance issue.
> > 
> > The benchmark is extending a TPM PCR with 12313 entries of the IMA
> > measurement list, and calculating the time elapsed for the
> > operation.
> > 
> > Without TPM HMAC: 102.8 seconds
> > 
> > With TPM HMAC: 1941.71 seconds
> 
> Jarkko patch set [1] improved the performance:
> 
> 404.4 seconds
> 
> 
> Still quite slow.

So this is now the internal TPM overhead.  There's not much we can do
in the kernel to optimize that.  Your own figures were

> No HMAC:
> 
> # tracer: function_graph
> #
> # CPU  DURATION                  FUNCTION CALLS
> # |     |   |                     |   |   |   |
>  0)               |  tpm2_pcr_extend() {
>  0)   1.112 us    |    tpm_buf_append_hmac_session();
>  0) # 6360.029 us |    tpm_transmit_cmd();
>  0) # 6415.012 us |  }
> 
> 
> HMAC:
> 
> # tracer: function_graph
> #
> # CPU  DURATION                  FUNCTION CALLS
> # |     |   |                     |   |   |   |
>  1)               |  tpm2_pcr_extend() {
>  1)               |    tpm2_start_auth_session() {
>  1) * 36976.99 us |      tpm_transmit_cmd();
>  1) * 84746.51 us |      tpm_transmit_cmd();
>  1) # 3195.083 us |      tpm_transmit_cmd();
>  1) @ 126795.1 us |    }
>  1)   2.254 us    |    tpm_buf_append_hmac_session();
>  1)   3.546 us    |    tpm_buf_fill_hmac_session();
>  1) * 24356.46 us |    tpm_transmit_cmd();
>  1)   3.496 us    |    tpm_buf_check_hmac_response();
>  1) @ 151171.0 us |  }

or 6ms for no session extend vs 24ms for with session extend, so
effectively 4x slower, which is exactly what the above figures are also
showing.

>  We should consider not only the boot performance.
> Depending on the use case, IMA can be used after boot and slow down
> applications performance.

Right, but this is IMA fish or cut bait time: are you willing to pay a
4x penalty for improved security, bearing in mind that not all TPMs
will show the 4x slow down, since some have much better optimized
crypto routines.  If yes, we can simply keep the no flush optimization.
If no, we'd have to turn off security for IMA extends

Regards,

James

Re: TPM HMAC (really) bad performance

[Mimi Zohar]

On Fri, 2024-09-27 at 10:15 -0400, James Bottomley wrote:
> On Fri, 2024-09-27 at 15:53 +0200, Roberto Sassu wrote:
> > On Fri, 2024-09-06 at 14:32 +0200, Roberto Sassu wrote:
> > > Hi all
> > > 
> > > when running the benchmark on my new component, the Integrity
> > > Digest
> > > Cache, I ran into a serious performance issue.
> > > 
> > > The benchmark is extending a TPM PCR with 12313 entries of the IMA
> > > measurement list, and calculating the time elapsed for the
> > > operation.
> > > 
> > > Without TPM HMAC: 102.8 seconds
> > > 
> > > With TPM HMAC: 1941.71 seconds
> > 
> > Jarkko patch set [1] improved the performance:
> > 
> > 404.4 seconds
> > 
> > 
> > Still quite slow.
> 
> So this is now the internal TPM overhead.  There's not much we can do
> in the kernel to optimize that.  Your own figures were
> 
> > No HMAC:
> > 
> > # tracer: function_graph
> > #
> > # CPU  DURATION                  FUNCTION CALLS
> > # |     |   |                     |   |   |   |
> >  0)               |  tpm2_pcr_extend() {
> >  0)   1.112 us    |    tpm_buf_append_hmac_session();
> >  0) # 6360.029 us |    tpm_transmit_cmd();
> >  0) # 6415.012 us |  }
> > 
> > 
> > HMAC:
> > 
> > # tracer: function_graph
> > #
> > # CPU  DURATION                  FUNCTION CALLS
> > # |     |   |                     |   |   |   |
> >  1)               |  tpm2_pcr_extend() {
> >  1)               |    tpm2_start_auth_session() {
> >  1) * 36976.99 us |      tpm_transmit_cmd();
> >  1) * 84746.51 us |      tpm_transmit_cmd();
> >  1) # 3195.083 us |      tpm_transmit_cmd();
> >  1) @ 126795.1 us |    }
> >  1)   2.254 us    |    tpm_buf_append_hmac_session();
> >  1)   3.546 us    |    tpm_buf_fill_hmac_session();
> >  1) * 24356.46 us |    tpm_transmit_cmd();
> >  1)   3.496 us    |    tpm_buf_check_hmac_response();
> >  1) @ 151171.0 us |  }
> 
> or 6ms for no session extend vs 24ms for with session extend, so
> effectively 4x slower, which is exactly what the above figures are also
> showing.
> 
> >  We should consider not only the boot performance.
> > Depending on the use case, IMA can be used after boot and slow down
> > applications performance.
> 
> Right, but this is IMA fish or cut bait time: are you willing to pay a
> 4x penalty for improved security, bearing in mind that not all TPMs
> will show the 4x slow down, since some have much better optimized
> crypto routines.  If yes, we can simply keep the no flush optimization.
> If no, we'd have to turn off security for IMA extends

Another way of looking at it is that the performance for existing TPMs is
unacceptable with CONFIG_TCG_TPM2_HMAC configured at least for the builtin
"ima_policy=tcb" policy, replaced with a similar custom policy.  Without
Jarkko's patch set it takes ~10 minutes to boot.  With Jarkko's patch set it
takes ~3 minutes. Saying it will work with newer, faster TPMs isn't a viable
solution for distros.  Either the Kconfig is turned on or not for all systems.

Is the reason for the performance degradation due to the HMAC or encryption?  If
the performance degradation is due to the HMAC, then the last line should be:
"Saying Y here adds some overhead to all kernel to TPM transactions".

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
        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
          here adds some encryption overhead to all kernel to TPM
          transactions.

I'm not quite sure what you mean by "If no, we'd have to turn off security for
IMA extends."  Are you leaving it enabled for all other TPM communication, just
disabling it for IMA or disabling it entirely based on whether IMA is
configured?

Mimi




 



 
 

Re: TPM HMAC (really) bad performance

[Mimi Zohar]

On Mon, 2024-09-30 at 10:09 -0400, Mimi Zohar wrote:
> On Fri, 2024-09-27 at 10:15 -0400, James Bottomley wrote:
> > On Fri, 2024-09-27 at 15:53 +0200, Roberto Sassu wrote:
> > > On Fri, 2024-09-06 at 14:32 +0200, Roberto Sassu wrote:
> > > > Hi all
> > > > 
> > > > when running the benchmark on my new component, the Integrity
> > > > Digest
> > > > Cache, I ran into a serious performance issue.
> > > > 
> > > > The benchmark is extending a TPM PCR with 12313 entries of the IMA
> > > > measurement list, and calculating the time elapsed for the
> > > > operation.
> > > > 
> > > > Without TPM HMAC: 102.8 seconds
> > > > 
> > > > With TPM HMAC: 1941.71 seconds
> > > 
> > > Jarkko patch set [1] improved the performance:
> > > 
> > > 404.4 seconds
> > > 
> > > 
> > > Still quite slow.
> > 
> > So this is now the internal TPM overhead.  There's not much we can do
> > in the kernel to optimize that.  Your own figures were
> > 
> > > No HMAC:
> > > 
> > > # tracer: function_graph
> > > #
> > > # CPU  DURATION                  FUNCTION CALLS
> > > # |     |   |                     |   |   |   |
> > >  0)               |  tpm2_pcr_extend() {
> > >  0)   1.112 us    |    tpm_buf_append_hmac_session();
> > >  0) # 6360.029 us |    tpm_transmit_cmd();
> > >  0) # 6415.012 us |  }
> > > 
> > > 
> > > HMAC:
> > > 
> > > # tracer: function_graph
> > > #
> > > # CPU  DURATION                  FUNCTION CALLS
> > > # |     |   |                     |   |   |   |
> > >  1)               |  tpm2_pcr_extend() {
> > >  1)               |    tpm2_start_auth_session() {
> > >  1) * 36976.99 us |      tpm_transmit_cmd();
> > >  1) * 84746.51 us |      tpm_transmit_cmd();
> > >  1) # 3195.083 us |      tpm_transmit_cmd();
> > >  1) @ 126795.1 us |    }
> > >  1)   2.254 us    |    tpm_buf_append_hmac_session();
> > >  1)   3.546 us    |    tpm_buf_fill_hmac_session();
> > >  1) * 24356.46 us |    tpm_transmit_cmd();
> > >  1)   3.496 us    |    tpm_buf_check_hmac_response();
> > >  1) @ 151171.0 us |  }
> > 
> > or 6ms for no session extend vs 24ms for with session extend, so
> > effectively 4x slower, which is exactly what the above figures are also
> > showing.
> > 
> > >  We should consider not only the boot performance.
> > > Depending on the use case, IMA can be used after boot and slow down
> > > applications performance.
> > 
> > Right, but this is IMA fish or cut bait time: are you willing to pay a
> > 4x penalty for improved security, bearing in mind that not all TPMs
> > will show the 4x slow down, since some have much better optimized
> > crypto routines.  If yes, we can simply keep the no flush optimization.
> > If no, we'd have to turn off security for IMA extends
> 
> Another way of looking at it is that the performance for existing TPMs is
> unacceptable with CONFIG_TCG_TPM2_HMAC configured at least for the builtin
> "ima_policy=tcb" policy, replaced with a similar custom policy.  Without
> Jarkko's patch set it takes ~10 minutes to boot.  With Jarkko's patch set it
> takes ~3 minutes. Saying it will work with newer, faster TPMs isn't a viable
> solution for distros.  Either the Kconfig is turned on or not for all systems.

FYI without CONFIG_TCG_TPM2_HMAC configured, with the the same "ima_policy=tcb"
builtin policy and custom policy it takes 49 seconds to boot.

> 
> Is the reason for the performance degradation due to the HMAC or encryption?  If
> the performance degradation is due to the HMAC, then the last line should be:
> "Saying Y here adds some overhead to all kernel to TPM transactions".
> 
> 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
>         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
>           here adds some encryption overhead to all kernel to TPM
>           transactions.
> 
> I'm not quite sure what you mean by "If no, we'd have to turn off security for
> IMA extends."  Are you leaving it enabled for all other TPM communication, just
> disabling it for IMA or disabling it entirely based on whether IMA is
> configured?
> 
> Mimi

Re: TPM HMAC (really) bad performance

[James Bottomley]

On Mon, 2024-09-30 at 10:09 -0400, Mimi Zohar wrote:
> On Fri, 2024-09-27 at 10:15 -0400, James Bottomley wrote:
> > On Fri, 2024-09-27 at 15:53 +0200, Roberto Sassu wrote:
> > > On Fri, 2024-09-06 at 14:32 +0200, Roberto Sassu wrote:
> > > > Hi all
> > > > 
> > > > when running the benchmark on my new component, the Integrity
> > > > Digest Cache, I ran into a serious performance issue.
> > > > 
> > > > The benchmark is extending a TPM PCR with 12313 entries of the
> > > > IMA measurement list, and calculating the time elapsed for the
> > > > operation.
> > > > 
> > > > Without TPM HMAC: 102.8 seconds
> > > > 
> > > > With TPM HMAC: 1941.71 seconds
> > > 
> > > Jarkko patch set [1] improved the performance:
> > > 
> > > 404.4 seconds
> > > 
> > > 
> > > Still quite slow.
> > 
> > So this is now the internal TPM overhead.  There's not much we can
> > do in the kernel to optimize that.  Your own figures were
> > 
> > > No HMAC:
> > > 
> > > # tracer: function_graph
> > > #
> > > # CPU  DURATION                  FUNCTION CALLS
> > > # |     |   |                     |   |   |   |
> > >  0)               |  tpm2_pcr_extend() {
> > >  0)   1.112 us    |    tpm_buf_append_hmac_session();
> > >  0) # 6360.029 us |    tpm_transmit_cmd();
> > >  0) # 6415.012 us |  }
> > > 
> > > 
> > > HMAC:
> > > 
> > > # tracer: function_graph
> > > #
> > > # CPU  DURATION                  FUNCTION CALLS
> > > # |     |   |                     |   |   |   |
> > >  1)               |  tpm2_pcr_extend() {
> > >  1)               |    tpm2_start_auth_session() {
> > >  1) * 36976.99 us |      tpm_transmit_cmd();
> > >  1) * 84746.51 us |      tpm_transmit_cmd();
> > >  1) # 3195.083 us |      tpm_transmit_cmd();
> > >  1) @ 126795.1 us |    }
> > >  1)   2.254 us    |    tpm_buf_append_hmac_session();
> > >  1)   3.546 us    |    tpm_buf_fill_hmac_session();
> > >  1) * 24356.46 us |    tpm_transmit_cmd();
> > >  1)   3.496 us    |    tpm_buf_check_hmac_response();
> > >  1) @ 151171.0 us |  }
> > 
> > or 6ms for no session extend vs 24ms for with session extend, so
> > effectively 4x slower, which is exactly what the above figures are
> > also showing.
> > 
> > >  We should consider not only the boot performance.
> > > Depending on the use case, IMA can be used after boot and slow
> > > down applications performance.
> > 
> > Right, but this is IMA fish or cut bait time: are you willing to
> > pay a 4x penalty for improved security, bearing in mind that not
> > all TPMs will show the 4x slow down, since some have much better
> > optimized crypto routines.  If yes, we can simply keep the no flush
> > optimization. If no, we'd have to turn off security for IMA extends
> 
> Another way of looking at it is that the performance for existing
> TPMs is unacceptable with CONFIG_TCG_TPM2_HMAC configured at least
> for the builtin "ima_policy=tcb" policy, replaced with a similar
> custom policy.  Without Jarkko's patch set it takes ~10 minutes to
> boot.  With Jarkko's patch set it takes ~3 minutes.

So that's the question: is 3 minutes acceptable?

>  Saying it will work with newer, faster TPMs isn't a viable solution
> for distros.  Either the Kconfig is turned on or not for all systems.
> 
> Is the reason for the performance degradation due to the HMAC or
> encryption?

It's the HMAC.  There's no security sensitive information in an extend
so no reason to do encrypt/decrypt as well.

>   If the performance degradation is due to the HMAC, then the last
> line should be:
> "Saying Y here adds some overhead to all kernel to TPM transactions".
> 
> 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
>         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
>           here adds some encryption overhead to all kernel to TPM
>           transactions.
> 
> I'm not quite sure what you mean by "If no, we'd have to turn off
> security for IMA extends."  Are you leaving it enabled for all other
> TPM communication,

Since IMA is the only current user of tpm2_pcr_extend() that's an
option, yes.  This would mean an interposer could intercept and either
discard or modify an extend without being detected.

>  just disabling it for IMA or disabling it entirely based on whether
> IMA is configured?

Since tpm2_pcr_extend() is unused if IMA is disabled, we don't really
need to condition on it, we could just remove the HMAC from extends.

James

Re: TPM HMAC (really) bad performance

[Mimi Zohar]

On Mon, 2024-09-30 at 17:16 -0700, James Bottomley wrote:
> On Mon, 2024-09-30 at 10:09 -0400, Mimi Zohar wrote:
> > On Fri, 2024-09-27 at 10:15 -0400, James Bottomley wrote:
> > > On Fri, 2024-09-27 at 15:53 +0200, Roberto Sassu wrote:
> > > > On Fri, 2024-09-06 at 14:32 +0200, Roberto Sassu wrote:
> > > > > Hi all
> > > > > 
> > > > > when running the benchmark on my new component, the Integrity
> > > > > Digest Cache, I ran into a serious performance issue.
> > > > > 
> > > > > The benchmark is extending a TPM PCR with 12313 entries of the
> > > > > IMA measurement list, and calculating the time elapsed for the
> > > > > operation.
> > > > > 
> > > > > Without TPM HMAC: 102.8 seconds
> > > > > 
> > > > > With TPM HMAC: 1941.71 seconds
> > > > 
> > > > Jarkko patch set [1] improved the performance:
> > > > 
> > > > 404.4 seconds
> > > > 
> > > > 
> > > > Still quite slow.
> > > 
> > > So this is now the internal TPM overhead.  There's not much we can
> > > do in the kernel to optimize that.  Your own figures were
> > > 
> > > > No HMAC:
> > > > 
> > > > # tracer: function_graph
> > > > #
> > > > # CPU  DURATION                  FUNCTION CALLS
> > > > # |     |   |                     |   |   |   |
> > > >  0)               |  tpm2_pcr_extend() {
> > > >  0)   1.112 us    |    tpm_buf_append_hmac_session();
> > > >  0) # 6360.029 us |    tpm_transmit_cmd();
> > > >  0) # 6415.012 us |  }
> > > > 
> > > > 
> > > > HMAC:
> > > > 
> > > > # tracer: function_graph
> > > > #
> > > > # CPU  DURATION                  FUNCTION CALLS
> > > > # |     |   |                     |   |   |   |
> > > >  1)               |  tpm2_pcr_extend() {
> > > >  1)               |    tpm2_start_auth_session() {
> > > >  1) * 36976.99 us |      tpm_transmit_cmd();
> > > >  1) * 84746.51 us |      tpm_transmit_cmd();
> > > >  1) # 3195.083 us |      tpm_transmit_cmd();
> > > >  1) @ 126795.1 us |    }
> > > >  1)   2.254 us    |    tpm_buf_append_hmac_session();
> > > >  1)   3.546 us    |    tpm_buf_fill_hmac_session();
> > > >  1) * 24356.46 us |    tpm_transmit_cmd();
> > > >  1)   3.496 us    |    tpm_buf_check_hmac_response();
> > > >  1) @ 151171.0 us |  }
> > > 
> > > or 6ms for no session extend vs 24ms for with session extend, so
> > > effectively 4x slower, which is exactly what the above figures are
> > > also showing.
> > > 
> > > >  We should consider not only the boot performance.
> > > > Depending on the use case, IMA can be used after boot and slow
> > > > down applications performance.
> > > 
> > > Right, but this is IMA fish or cut bait time: are you willing to
> > > pay a 4x penalty for improved security, bearing in mind that not
> > > all TPMs will show the 4x slow down, since some have much better
> > > optimized crypto routines.  If yes, we can simply keep the no flush
> > > optimization. If no, we'd have to turn off security for IMA extends
> > 
> > Another way of looking at it is that the performance for existing
> > TPMs is unacceptable with CONFIG_TCG_TPM2_HMAC configured at least
> > for the builtin "ima_policy=tcb" policy, replaced with a similar
> > custom policy.  Without Jarkko's patch set it takes ~10 minutes to
> > boot.  With Jarkko's patch set it takes ~3 minutes.
> 
> So that's the question: is 3 minutes acceptable?

There's no possible way of knowing how IMA is currently being used or whether
this performance degradation would be acceptable in all cases.

> >  Saying it will work with newer, faster TPMs isn't a viable solution
> > for distros.  Either the Kconfig is turned on or not for all systems.
> > 
> > Is the reason for the performance degradation due to the HMAC or
> > encryption?
> 
> It's the HMAC.  There's no security sensitive information in an extend
> so no reason to do encrypt/decrypt as well.

Agreed

> 
> >   If the performance degradation is due to the HMAC, then the last
> > line should be:
> > "Saying Y here adds some overhead to all kernel to TPM transactions".
> > 
> > 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
> >         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
> >           here adds some encryption overhead to all kernel to TPM
> >           transactions.
> > 
> > I'm not quite sure what you mean by "If no, we'd have to turn off
> > security for IMA extends."  Are you leaving it enabled for all other
> > TPM communication,
> 
> Since IMA is the only current user of tpm2_pcr_extend() that's an
> option, yes.  This would mean an interposer could intercept and either
> discard or modify an extend without being detected.

From an attestation perspective, assuming that the measurement list wasn't
compromised as well, discarding/modifying the extend would be detected by the
attestation service.  Modifying a different PCR, however, could potentially be a
problem.

> 
> >  just disabling it for IMA or disabling it entirely based on whether
> > IMA is configured?
> 
> Since tpm2_pcr_extend() is unused if IMA is disabled, we don't really
> need to condition on it, we could just remove the HMAC from extends.

Ok, so defining a new Kconfig is unnecessary.

Mimi

Re: TPM HMAC (really) bad performance

[Mimi Zohar]

On Mon, 2024-09-30 at 23:13 -0400, Mimi Zohar wrote:
> > 
> > >   just disabling it for IMA or disabling it entirely based on whether
> > > IMA is configured?
> > 
> > Since tpm2_pcr_extend() is unused if IMA is disabled, we don't really
> > need to condition on it, we could just remove the HMAC from extends.
> 
> Ok, so defining a new Kconfig is unnecessary.

IMA is enabled at boot/runtime, based on loading a policy.  Similarly the TPM
HMAC performance impact decision at least for IMA needs to be left with the
system owner, not with the person building the kernel.  My suggestion would be
to define an IMA boot command line option that enables TPM HMAC.  Without the
boot command line option, a warning should be emitted.

Mimi