[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <D46RWPQ211ZS.12EYKZY053BH@kernel.org>
Date: Sun, 15 Sep 2024 13:07:57 +0300
From: "Jarkko Sakkinen" <jarkko@...nel.org>
To: "Jarkko Sakkinen" <jarkko@...nel.org>, "Roberto Sassu"
<roberto.sassu@...weicloud.com>, "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 Sun Sep 15, 2024 at 12:43 PM EEST, Jarkko Sakkinen wrote:
> When it comes to boot we should aim for one single start_auth_session
> during boot, i.e. different phases would leave that session open so
> that we don't have to load the context every single time. I think it
> should be doable.
The best possible idea how to improve performance here would be to
transfer the cost from time to space. This can be achieved by keeping
null key permanently in the TPM memory during power cycle.
It would give about 80% increase given Roberto's benchmark to all
in-kernel callers. There's no really other possible solution for this
to make any major improvements. So after opt-in kernel command line
option I might look into this.
This is already done locally in tpm2_get_random(), which uses
continueSession to keep session open for all calls.
BR, Jarkko
Powered by blists - more mailing lists