Re: TPM HMAC (really) bad performance

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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





[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux Kernel]     [Linux Kernel Hardening]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux SCSI]

  Powered by Linux