On Sat Sep 21, 2024 at 6:40 PM EEST, Jarkko Sakkinen wrote: > On Sun Sep 15, 2024 at 7:22 PM EEST, Jarkko Sakkinen wrote: > > 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. > > "my theory" worked pretty well. It brought the boot time back to 8.7s, > which can be explained with encryption overhead pretty well. > > I'd suggest reading the bug report next time before solving a problem > that did not exist. We care about users, not unfinished patch sets. I'd also expect to review a patch set that fixes a performance issue caused by a feature that you implemented less than a one week. One that doubles the boot time on AMD CPU's. This is ridiculous tbh. BR, Jarkko
