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] [thread-next>] [day] [month] [year] [list]

Message-ID: <0b22c2c4b4a998fb44bb08be60a359acb9ecb8da.camel@HansenPartnership.com>
Date: Sun, 15 Sep 2024 09:59:43 -0400
From: James Bottomley <James.Bottomley@...senPartnership.com>
To: Jarkko Sakkinen <jarkko@...nel.org>, 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, 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.

> It would give about 80% increase given Roberto's benchmark to all
> in-kernel callers. There's no really other possible solution for this
> to make any major improvements. So after opt-in kernel command line
> option I might look into this.
> 
> This is already done locally in tpm2_get_random(), which uses
> continueSession to keep session open for all calls.

The other problem if the session is context saved, as I already said,
is that it becomes long lived and requires degapping the session
manager.

James