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
