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.
