public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Jarkko Sakkinen" <jarkko@kernel.org>
To: "James Bottomley" <James.Bottomley@HansenPartnership.com>,
	"Roberto Sassu" <roberto.sassu@huaweicloud.com>,
	"Linux regressions mailing list" <regressions@lists.linux.dev>
Cc: <keyrings@vger.kernel.org>,
	"linux-integrity@vger.kernel.org"
	<linux-integrity@vger.kernel.org>,
	"LKML" <linux-kernel@vger.kernel.org>,
	"Pengyu Ma" <mapengyu@gmail.com>
Subject: Re: [regression] significant delays when secureboot is enabled since 6.10
Date: Sun, 15 Sep 2024 19:22:04 +0300	[thread overview]
Message-ID: <D46ZV5RXW7Z9.26N1IRXNRLV9X@kernel.org> (raw)
In-Reply-To: <7586c7e6e6028a734a8cac3d4b1a8504e6cd4b21.camel@HansenPartnership.com>

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.

BR, Jarkko

  reply	other threads:[~2024-09-15 16:22 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-10  9:01 [regression] significant delays when secureboot is enabled since 6.10 Linux regression tracking (Thorsten Leemhuis)
2024-09-10  9:05 ` Roberto Sassu
2024-09-10 12:39   ` Jarkko Sakkinen
2024-09-10 12:48     ` Jarkko Sakkinen
2024-09-10 12:57       ` James Bottomley
2024-09-10 13:28         ` Jarkko Sakkinen
2024-09-11  8:53           ` Roberto Sassu
2024-09-11 12:21             ` James Bottomley
2024-09-12 13:16               ` Jarkko Sakkinen
2024-09-12 13:26                 ` James Bottomley
2024-09-12 13:36                   ` Roberto Sassu
2024-09-12 14:13                     ` James Bottomley
2024-09-12 14:52                       ` Roberto Sassu
2024-09-12 14:26                   ` Jarkko Sakkinen
2024-09-14 10:42               ` Jarkko Sakkinen
2024-09-14 10:51                 ` Jarkko Sakkinen
2024-09-14 10:58                   ` Jarkko Sakkinen
2024-09-11 15:14             ` Jarkko Sakkinen
2024-09-12  8:13               ` Roberto Sassu
2024-09-12 14:23                 ` Jarkko Sakkinen
2024-09-13 20:50                 ` Jarkko Sakkinen
2024-09-13 22:06                   ` Jarkko Sakkinen
2024-09-15  9:43                 ` Jarkko Sakkinen
2024-09-15 10:07                   ` Jarkko Sakkinen
2024-09-15 13:59                     ` James Bottomley
2024-09-15 14:50                       ` Jarkko Sakkinen
2024-09-15 14:55                         ` Jarkko Sakkinen
2024-09-15 15:00                         ` James Bottomley
2024-09-15 16:22                           ` Jarkko Sakkinen [this message]
2024-09-21 15:40                             ` Jarkko Sakkinen
2024-09-22 14:11                               ` Jarkko Sakkinen
2024-09-10 12:22 ` James Bottomley
2024-09-10 12:41   ` Linux regression tracking (Thorsten Leemhuis)
2024-09-10 22:40     ` Jarkko Sakkinen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=D46ZV5RXW7Z9.26N1IRXNRLV9X@kernel.org \
    --to=jarkko@kernel.org \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=keyrings@vger.kernel.org \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mapengyu@gmail.com \
    --cc=regressions@lists.linux.dev \
    --cc=roberto.sassu@huaweicloud.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox