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

[Jarkko Sakkinen]

On Tue Sep 10, 2024 at 3:39 PM EEST, Jarkko Sakkinen wrote:
> On Tue Sep 10, 2024 at 12:05 PM EEST, Roberto Sassu wrote:
> > On Tue, 2024-09-10 at 11:01 +0200, Linux regression tracking (Thorsten
> > Leemhuis) wrote:
> > > Hi, Thorsten here, the Linux kernel's regression tracker.
> > > 
> > > James, Jarkoo, I noticed a report about a regression in
> > > bugzilla.kernel.org that appears to be caused by this change of yours:
> > > 
> > > 6519fea6fd372b ("tpm: add hmac checks to tpm2_pcr_extend()") [v6.10-rc1]
> > > 
> > > As many (most?) kernel developers don't keep an eye on the bug tracker,
> > > I decided to forward it by mail. To quote from
> > > https://bugzilla.kernel.org/show_bug.cgi?id=219229 :
> > > 
> > > > When secureboot is enabled,
> > > > the kernel boot time is ~20 seconds after 6.10 kernel.
> > > > it's ~7 seconds on 6.8 kernel version.
> > > > 
> > > > When secureboot is disabled,
> > > > the boot time is ~7 seconds too.
> > > > 
> > > > Reproduced on both AMD and Intel platform on ThinkPad X1 and T14.
> > > > 
> > > > It probably caused autologin failure and micmute led not loaded on AMD platform.
> > > 
> > > It was later bisected to the change mentioned above. See the ticket for
> > > more details.
> >
> > Hi
> >
> > I suspect I encountered the same problem:
> >
> > https://lore.kernel.org/linux-integrity/b8a7b3566e6014ba102ab98e10ede0d574d8930e.camel@xxxxxxxxxxxxxxx/
> >
> > Going to provide more info there.
>
> I suppose you are going try to acquire the tracing data I asked?
> That would be awesome, thanks for taking the troube.  Let's look
> at the data and draw conclusions based on that.
>
> Workaround is pretty simple: CONFIG_TCG_TPM2_HMAC=n to the kernel
> configuration disables the feature.
>
> For making decisions what to do with the  we are talking about ~2
> week window estimated, given the Vienna conference slows things
> down, so I hope my workaround is good enough before that.

I can enumerate three most likely ways to address the issue:

1. Strongest: drop from defconfig.
2. Medium: leave to defconfig but add an opt-in kernel command-line
   parameter.
3. Lightest: if we can based on tracing data nail the regression in
   sustainable schedule, fix it.

Without data it is impossible to point out the right choice (or
some unknown alternative that has not crossed my mind yet).

BR, Jarkko