On Fri Sep 13, 2024 at 11:50 PM EEST, Jarkko Sakkinen wrote:
> On Thu Sep 12, 2024 at 11:13 AM EEST, Roberto Sassu wrote:
> > On Wed, 2024-09-11 at 18:14 +0300, Jarkko Sakkinen wrote:
> > > On Wed Sep 11, 2024 at 11:53 AM EEST, Roberto Sassu wrote:
> > > > I made few measurements. I have a Fedora 38 VM with TPM passthrough.
> > >
> > > I was thinking more like
> > >
> > > sudo bpftrace -e 'k:tpm_transmit { @start[tid] = nsecs; } kr:tpm_transmit { @[kstack, ustack, comm] = sum(nsecs - @start[tid]); delete(@start[tid]); } END { clear(@start); }'
> > >
> > > For example when running "tpm2_createprimary --hierarchy o -G rsa2048 -c owner.txt", I get:
> >
> > Sure:
>
> Took couple of days to upgrade my BuildRoot environment to have bcc and
> bpftrace [1] but finally got similar figures (not the same test but doing
> extends).
>
> Summarizing your results looking at call before tpm_transmit:
>
> - HMAC management: 124 ms
> - extend with HMAC: 25 ms
> - extend without HMAC: 5.2 ms
>
> I'd see the only possible way to fix this would be refactor the HMAC
> implementation by making the caller always the orchestrator and thus
> allowing to use continueSession flag for TPM2_StartAuthSession to be
> used.
>
> For example if you do multiple extends there should not be good reason
> to setup and rollback session for each call separately right?
>
> [1] https://codeberg.org/jarkko/linux-tpmdd-test
Note that the timings are accumulated (not averaged). It would be easy
to fix this tho.
BR, Jarkko
