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
