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: <D46Y0YJMYUBV.3C6B6Q5HHGGA4@kernel.org>
Date: Sun, 15 Sep 2024 17:55:36 +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 5:50 PM EEST, Jarkko Sakkinen wrote:
> One low-hanging fruit improvement in the startup code is the handling
> of null key. If it was flushed only on need, which means in practice
> access to /dev/tpm0 or /dev/tpmrm0
>
> I'm already working on patch set which adds chip->null_key that will
> be flushed on-need basis only. I can measure with qemu how it affects
> boot time.

I can agree with that playing continueSession is not like the first
thing to try out but keeping null key in memory as long as it can be
does not affect context gap so I start experimenting with that.

BR, Jarkko

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ