Hi,
On 20.02.24 19:42, Alexander Steffen wrote: > On 02.02.2024 04:08, Lino Sanfilippo wrote: >> On 01.02.24 23:21, Jarkko Sakkinen wrote: >> >>> >>> On Wed Jan 31, 2024 at 7:08 PM EET, Daniel P. Smith wrote: >>>> Commit 933bfc5ad213 introduced the use of a locality counter to control >>>> when a >>>> locality request is allowed to be sent to the TPM. In the commit, the >>>> counter >>>> is indiscriminately decremented. Thus creating a situation for an integer >>>> underflow of the counter. >>> >>> What is the sequence of events that leads to this triggering the >>> underflow? This information should be represent in the commit message. >>> >> >> AFAIU this is: >> >> 1. We start with a locality_counter of 0 and then we call >> tpm_tis_request_locality() >> for the first time, but since a locality is (unexpectedly) already active >> check_locality() and consequently __tpm_tis_request_locality() return "true". > > check_locality() returns true, but __tpm_tis_request_locality() returns the > requested locality. Currently, this is always 0, so the check for !ret will > always correctly indicate success and increment the locality_count. So how was the reported underflow triggered then? We only request locality 0 in TPM TIS core, no other locality. > > But since theoretically a locality != 0 could be requested, the correct fix > would be to check for something like ret >= 0 or ret == l instead of !ret. I thought that the underflow issue has actually been triggered and is not only a theoretical problem. But now I wonder how this could ever happen. BR, Lino
