From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B915618B04; Sun, 15 Sep 2024 14:55:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1726412140; cv=none; b=TYWagNlAV7OnbKgLWP+67ykJQuojGazKLWO/4XjaHCsk07pBHkXnlBxbzBqcBF8CEbPW0IjBLRgQifupAi2rDDzSLqbaJ1UR5+UHGVEk1GX70F06ImCkTzDzs3t47Q4wGQ4uJM5VfKEMyVhuIpGezyKZQy7Sw9OLN5Niq55Yk4U= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1726412140; c=relaxed/simple; bh=eDYVAMcB9QXm8GrzzyxMlsOWCnurPxa71hepbHj+9TI=; h=Mime-Version:Content-Type:Date:Message-Id:From:To:Cc:Subject: References:In-Reply-To; b=RtiBH2lVcNT27v2w11nZt35XyHHAAu97h4ebaZ7UYFJtMhRwm8FjkwsXg/c7hewykJ5dR6AClvLEahUhuArjuuPrYK3vA8U0YtEM97EStQo/wQ5y82plHStZcbn6oHDWTkGaUOgIdgvMIBNDsWSX4DL/KsMAfOfWfDzeBa2PfSI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=dnwIrAud; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="dnwIrAud" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D5052C4CECC; Sun, 15 Sep 2024 14:55:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1726412140; bh=eDYVAMcB9QXm8GrzzyxMlsOWCnurPxa71hepbHj+9TI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=dnwIrAudOF10nzuCpxUNX6udxK9X/qVCFlBwTSscOzxCM0FHcbYOTb/VU8Yndbnpf yW+FLC10BCQGIl3UfJm5xVfyM4g+1wG9ImoHNj65kaiQdKzhkrTWAyPxyHLizEE2x8 qq4CFxQeM5FHJvMOSrVVoAAYecJ5qubeYvt4zi0l5Y+s8kV5lEs2AkuYDJfiEI+3VJ GhbazNapwyO3EE74WLUounVrJy1unwfK4yLmXI/4vsklNj63hLDxy25rvX6RIrMAFt yt1v2kT2d9nKvaejD1KQjtDDq5fQCX5dxMxITMfcmqJ+HzLA2TnZNMBR4+M+QZGm+H +PvbUT9fCVYmw== Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Sun, 15 Sep 2024 17:55:36 +0300 Message-Id: From: "Jarkko Sakkinen" To: "Jarkko Sakkinen" , "James Bottomley" , "Roberto Sassu" , "Linux regressions mailing list" Cc: , "linux-integrity@vger.kernel.org" , "LKML" , "Pengyu Ma" Subject: Re: [regression] significant delays when secureboot is enabled since 6.10 X-Mailer: aerc 0.18.2 References: <0b4a5a86-a9f6-42d1-a9ba-ec565b336d3a@leemhuis.info> <92fbcc4c252ec9070d71a6c7d4f1d196ec67eeb0.camel@huaweicloud.com> <663d272617d1aead08077ad2b72929cbc226372a.camel@HansenPartnership.com> <7e47f97aede88b87fbb9c9284db2005764bfbedd.camel@huaweicloud.com> <0b22c2c4b4a998fb44bb08be60a359acb9ecb8da.camel@HansenPartnership.com> In-Reply-To: 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