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 for Android: free password hash cracker in your pocket

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

Message-Id: <D45Y78TPNUC3.VPF1BWS5EI0Q@iki.fi>
Date: Sat, 14 Sep 2024 13:51:08 +0300
From: "Jarkko Sakkinen" <jarkko.sakkinen@....fi>
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 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.

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? 

BR, Jarkko