Re: [regression] significant delays when secureboot is enabled since 6.10

["Jarkko Sakkinen" <jarkko@kernel.org>]

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

>
> > 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.

I don't really care what you claim, I care what you code only at most.
Especially when topic shifted like it was now to IMA, which feels to
me like misguided communication tbh.

I don't think a round trip in kernel would qualify in that but there
is more low-hanging fruit too.

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.

BR, Jarkko