[PATCH v5 0/5] Lazy flush for the auth session

[James Bottomley]

On Tue, 2024-09-24 at 19:29 +0300, Jarkko Sakkinen wrote:
> On Tue Sep 24, 2024 at 4:48 PM EEST, James Bottomley wrote:
[...]
> > Patch 3 is completely unnecessary: the null key is only used to
> > salt the session and is not required to be resident while the
> > session is used (so can be flushed after session creation)
> > therefore keeping it around serves no purpose once the session is
> > created and simply clutters up the TPM volatile handle slots. (I
> > don't know of a case where we use all the slots in a kernel
> > operation, but since we don't need it lets not find out when we get
> > one).  So I advise dropping patch 3.
> 
> Let's go this through just to check I'm understanding.
> 
> Holding null key had radical effect on boot time: it cut it down by
> 5 secons down to 15 seconds:
> 
> https://lore.kernel.org/linux-integrity/CALSz7m1WG7fZ9UuO0URgCZEDG7r_wB4Ev_4mOHJThH_d1Ed1nw@mail.gmail.com/
> 
> Then in subsequent version I implemented lazy auth session and boot
> time went down to 9.7 seconds.
> 
> So is the point you're trying to make that since auth session is 
> already held as long as we can and they flushed in synchronous
> point too, I can just as well drop patch 3?

Yes, because the null key is only used in session generation which is
now lazy, it adds or subtracts nothing from the timings.  When you're
forced to flush the session, the null key goes too, so you again have
to restore it from the context.  When you can keep the session you
don't need the null key because you're not regenerating it.

> I think I reach your point but just want to check that I do it
> for the matching reasons. It is evolutionary cruft in the patch
> set :-)

Regards,

James