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: Windows password security audit tool. GUI, reports in PDF.

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

Message-Id: <D4C2QDK9WGUH.KQCJ19C43ONW@kernel.org>
Date: Sat, 21 Sep 2024 18:40:12 +0300
From: "Jarkko Sakkinen" <jarkko@...nel.org>
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 Sun Sep 15, 2024 at 7:22 PM EEST, Jarkko Sakkinen wrote:
> On Sun Sep 15, 2024 at 6:00 PM EEST, James Bottomley wrote:
> > On Sun, 2024-09-15 at 17:50 +0300, Jarkko Sakkinen wrote:
> > > On Sun Sep 15, 2024 at 4:59 PM EEST, James Bottomley wrote:
> > > > On Sun, 2024-09-15 at 13:07 +0300, Jarkko Sakkinen wrote:
> > > > > On Sun Sep 15, 2024 at 12:43 PM EEST, Jarkko Sakkinen wrote:
> > > > > > When it comes to boot we should aim for one single
> > > > > > start_auth_session during boot, i.e. different phases would
> > > > > > leave that session open so that we don't have to load the
> > > > > > context every single time.  I think it should be doable.
> > > > > 
> > > > > The best possible idea how to improve performance here would be
> > > > > to transfer the cost from time to space. This can be achieved by
> > > > > keeping null key permanently in the TPM memory during power
> > > > > cycle.
> > > > 
> > > > No it's not at all.  If you look at it, the NULL key is only used
> > > > to encrypt the salt for the start session and that's the operating
> > > > taking a lot of time.  That's why the cleanest mitigation would be
> > > > to save and restore the session.  Unfortunately the timings you
> > > > already complain about still show this would be about 10x longer
> > > > than a no-hmac extend so I'm still waiting to see if IMA people
> > > > consider that an acceptable tradeoff.
> > > 
> > > The bug report does not say anything about IMA issues. Please read
> > > the bug reports before commenting ;-) I will ignore your comment
> > > because it is plain misleading information.
> > > 
> > > https://bugzilla.kernel.org/show_bug.cgi?id=219229
> >
> > Well, given that the kernel does no measured boot extends after the EFI
> > boot stub (which isn't session protected) finishes, what's your theory
> > for the root cause?
>
> I don't think there is a silver bullet. Based on benchmark which showed
> 80% overhead from throttling the context reducing number of loads and
> saves will cut a slice of the fat.
>
> Since it is the low-hanging fruit I'll start with that. In other words,
> I'm not going touch session loading and saving. I'll start with null
> key loading and saving.

"my theory" worked pretty well. It brought the boot time back to 8.7s,
which can be explained with encryption overhead pretty well.

I'd suggest reading the bug report next time before solving a problem
that did not exist. We care about users, not unfinished patch sets.

BR, Jarkko