[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <D45YD8TVSHUH.227AS0RCL2DP3@iki.fi>
Date: Sat, 14 Sep 2024 13:58:59 +0300
From: "Jarkko Sakkinen" <jarkko.sakkinen@....fi>
To: "Jarkko Sakkinen" <jarkko.sakkinen@....fi>, "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 Sat Sep 14, 2024 at 1:51 PM EEST, Jarkko Sakkinen wrote:
> On Sat Sep 14, 2024 at 1:42 PM EEST, Jarkko Sakkinen wrote:
> > Please address how this discussion is related to https://bugzilla.kernel.org/show_bug.cgi?id=219229
> >
> > I just read the bug report nothing about IMA or PCR extend.
> >
> > There's now tons of spam about performance issue in a patch set that is
> > not in the mainline and barely nothing about the original issue:
> >
> > "
> > 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.
> >
> > 6.9 kernel version is not tested since not signed kernel found.
> > 6.8, 6.10, 6.11 are tested, the first bad version is 6.10.
> > "
> >
> > How is this going to help to fix this one?
> >
> > I say this once and one: I zero care fixing code that is in the
> > mainline.
"not in the mainline" (oops)
>
> How do we now that bug is anything to do with IMA? I'm having a weekend
> now but on Monday I'll ask the kconfig from the reporter. I think
> important thing is to then revisit how many times the session is setup
> during boot and make conclusions from that.
>
> It is plain wrong and immoral to convolute a regression with marketing
> a new kernel feature. These topics should be brought up in the topic
> (i.e. patch set comments), not here. It misleads everyone.
>
> Please explain me how this is going to help the reporter in any
> possible?
I will check the original reporters kconfig once I get it. Based on
that I can reverse TPM call sequences. Based on those I check if
anything can be orchestrated.
If this leads no results I just send a patch that makes the whole
feature as an opt-in kernel command-line option and call it a day.
I think we can the full next week timeline for this not going to
hold longer than that.
Any comments that are related to Roberto's unfinished patch set
take them elsewhere.
BR, Jarkko
Powered by blists - more mailing lists