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: <db275ab4fb73fc089c66738ffbcab23557e53055.camel@HansenPartnership.com>
Date: Tue, 10 Sep 2024 08:22:00 -0400
From: James Bottomley <James.Bottomley@...senPartnership.com>
To: Linux regressions mailing list <regressions@...ts.linux.dev>, Jarkko
	Sakkinen <jarkko@...nel.org>
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, 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.

We always suspected encryption and hmac would add overheads which is
why it's gated by a config option.  The way to fix this is to set

CONFIG_TCG_TPM_HMAC to N

of course, TPM transactions are then insecure, but it's the same state
as you were in before.

James



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ