On Fri Feb 23, 2024 at 3:56 AM EET, Daniel P. Smith wrote:
> On 2/20/24 15:54, Lino Sanfilippo wrote:
> > Hi,
> >
> > On 20.02.24 19:42, Alexander Steffen wrote:
> >> ATTENTION: This e-mail is from an external sender. Please check attachments and links before opening e.g. with mouseover.
> >>
> >>
> >> 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.
> >>
> >
> > Will the TPM TIS CORE ever (have to) request another locality than 0? Maybe the best would
> > be to hardcode TPM_ACCESS(0) and get rid of all the locality parameters that are
> > passed from one function to another.
> > But this is rather code optimization and not really required to fix the reported bug.
>
> Actually, doing so will break the TPM API. The function
> tpm_tis_request_locality() is registered as the locality handler,
> int (*request_locality)(struct tpm_chip *chip, int loc), in the tis
> instance of struct tpm_class_ops{}. This is the API used by the Secure
> Launch series to open Locality2 for the measurements it must record.
OK, based on James' earlier feedback on possibility to have kernel
specific locality and this , and some reconsideration of my position on
the topic, and reading all these great and informative responses, I
think I went too far with this :-)
>
> v/r,
> dps
BR, Jarkko
