linux-kernel - Re: [regression] significant delays when secureboot is enabled since 6.10

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <D45GBJ51SBNP.1WR34VCVNSN52@iki.fi>
Date: Fri, 13 Sep 2024 23:50:24 +0300
From: "Jarkko Sakkinen" <jarkko.sakkinen@....fi>
To: "Roberto Sassu" <roberto.sassu@...weicloud.com>, "Jarkko Sakkinen"
 <jarkko@...nel.org>, "James Bottomley"
 <James.Bottomley@...senPartnership.com>, "Linux regressions mailing list"
 <regressions@...ts.linux.dev>
Cc: <keyrings@...r.kernel.org>, "linux-integrity@...r.kernel.org"
 <linux-integrity@...r.kernel.org>, "LKML" <linux-kernel@...r.kernel.org>,
 "Pengyu Ma" <mapengyu@...il.com>
Subject: Re: [regression] significant delays when secureboot is enabled
 since 6.10

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

BR, Jarkko