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

[James Bottomley]

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@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.

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)

The down side of doing this is that an interposer can drop any extend
it wants without being immediately detected, but as long as they don't
have control of the kernel they can't change the log entry, so the
mismatch would be detected on check (which has to be done by the remote
verifier).  The unavoidable increased threat is that if you get tricked
into booting a malicious kernel (so the attacker has control of the
log) and the interposer substitutes the boot measurements, it can
actually fake out a remote verification system into thinking you're
actually a good node.

James