[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <D46Y0YJMYUBV.3C6B6Q5HHGGA4@kernel.org>
Date: Sun, 15 Sep 2024 17:55:36 +0300
From: "Jarkko Sakkinen" <jarkko@...nel.org>
To: "Jarkko Sakkinen" <jarkko@...nel.org>, "James Bottomley"
<James.Bottomley@...senPartnership.com>, "Roberto Sassu"
<roberto.sassu@...weicloud.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 5:50 PM EEST, Jarkko Sakkinen wrote:
> One low-hanging fruit improvement in the startup code is the handling
> of null key. If it was flushed only on need, which means in practice
> access to /dev/tpm0 or /dev/tpmrm0
>
> I'm already working on patch set which adds chip->null_key that will
> be flushed on-need basis only. I can measure with qemu how it affects
> boot time.
I can agree with that playing continueSession is not like the first
thing to try out but keeping null key in memory as long as it can be
does not affect context gap so I start experimenting with that.
BR, Jarkko
Powered by blists - more mailing lists