On Mon, Feb 10, 2025 at 07:32:53PM +0200, Jarkko Sakkinen wrote: > On Mon Feb 10, 2025 at 6:18 PM EET, Jonathan McDowell wrote: > > Who then handles the ERESTARTSYS though? Part of the issues we've seen > > is the failure happens in a context save or load, which is all within > > the kernel rather than directly under the control of userspace. I'm > > guessing the HMAC changes are likely to hit similar problems. I think > > some level of timeout improvement in tpm_transmit is appropriate, if we > > can work out what it should be. > > Right I get what you mean, not all transmits initiate from syscalls > And obviously this can happen without hmac too with tpmrm0. > > Hmm... so I'm open for a patch that radically simplifies the state > change timeouts, i.e. sort of part of that old patch. There is also another aspect to this: What happens when the context save/load result is dropped on the floor? There was other call that can take a very long time: get random number. And while dropping a random number that took a long time ito fabricate on the floor is wasteful it does not cause any real problem. With the context save/load, however, the context state gets desynchronized between TPM and kernel when the result of the call is ignored. If the kernel cannot correct the state by examining return value from later calls the TPM can effectively become defunct because the kernel will call the wrong context operation, it will return unexpected value which the kernel interprets as failure, and no operation can be performed. Thanks Michal
