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
