On Mon, Feb 24, 2025 at 02:04:13PM +0100, Michal Suchánek wrote: > 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? Trying to understand what are you meaning by this. Are you speaking about scenario where after the operation context operations fail inside kernel? > > 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. I got lost in the beginning so not yet sure about this (not same as rejecting, also I'm responding from holiday). Not really sure if this related but I'll just this here. We could possibly identify some expensive TPM commands that fill these requirements: 1. Don't run in a session. 2. Don't cause handles to be created (neither sessions nor objects). and executed as they were put to /dev/tpm0. At least we might be able to do this for TPM2_GetRandom. > > Thanks > > Michal BR, Jarkko
