[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <D42N17MFTEDM.3E6IK034S26UT@kernel.org>
Date: Tue, 10 Sep 2024 16:28:04 +0300
From: "Jarkko Sakkinen" <jarkko@...nel.org>
To: "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 Tue Sep 10, 2024 at 3:57 PM EEST, James Bottomley wrote:
> On Tue, 2024-09-10 at 15:48 +0300, Jarkko Sakkinen wrote:
> > 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@huaweicloud.com/
> > > >
> > > > 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.
>
> Actually, there's a fourth: not use sessions for the PCR extend (if
> we'd got the timings when I asked, this was going to be my suggestion
> if they came back problematic). This seems only to be a problem for
> IMA measured boot (because it does lots of extends). If necessary this
> could even be wrapped in a separate config or boot option that only
> disables HMAC on extend if IMA (so we still get security for things
> like sd-boot)
I can buy that but with a twist that make it an opt-in kernel command
line option. We don't want to take already existing functionality away
from those who might want to use it (given e.g. hardening requirements),
and with that basis opt-in (by default disabled) would be more balanced
way to address the issue.
Please do a send a patch!
BR, Jarkko
Powered by blists - more mailing lists