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
