On 2/12/24 15:05, Jarkko Sakkinen wrote:
On Fri Feb 2, 2024 at 5:08 AM EET, 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". This prevents the locality_counter from being increased
to 1, see
ret = __tpm_tis_request_locality(chip, l);
if (!ret) /* Counter not increased since ret == 1 */
priv->locality_count++;
in tpm_tis_request_locality().
If now the locality is released the counter is decreased to below zero (resulting
in an underflow since "locality_counter" is an unsigned int.
Thanks, Daniel, can you transcript this to the commit message?
ack
v/r,
dps
