Re: [PATCH] tpm_tis: Hold locality open during probe

[Jason Andryuk]

On Mon, Jul 11, 2022 at 3:37 PM Jason Andryuk <jandryuk@xxxxxxxxx> wrote:
>
> On Sun, Jul 10, 2022 at 10:58 PM Jarkko Sakkinen <jarkko@xxxxxxxxxx> wrote:
> >
> > Can you test against
> >
> > https://lore.kernel.org/linux-integrity/20220629232653.1306735-1-LinoSanfilippo@xxxxxx/T/#t
>
> I applied on top of 5.15.53, and the probe on boot still fails.
> Manually probing works intermittently.

On top of Lino Sanfilippo's patch queue, I added an additional
tpm_tis_request_locality and tpm_tis_release_locality to hold the
locality open via refcount in tpm_tis_chip_init.  Similar to my patch
in this thread, it acquires the locality before the TPM_INT_ENABLE
write and holds it until after the TPM_RID read.  That fixes the probe
issue on the box where I tested.

While tpm_tis_core_init is definitely a problem, I wonder if there are
other code paths that could trigger this  acquire -> release ->
acquire issue.  In that light, restoring a wait by reverting commit
e42acf104d6e ("tpm_tis: Clean up locality release") seems safer since
it would cover any code path.  I just tested reverting that and it
still fails to probe on boot and intermittently.  I'm surprised since
I expected it to solve the issue, but my original debugging was
showing TPM_ACCESS_ACTIVE_LOCALITY cleared (and never re-set) so the
driver isn't actually waiting.

All this locality acquiring and releasing seems rather redundant.  If
locality 0 is all that is ever used, why not just hold it open?  I
guess Trench Boot/Secure Launch wants to use locality 2
(https://lore.kernel.org/lkml/1645070085-14255-13-git-send-email-ross.philipson@xxxxxxxxxx/),
but in either case doesn't the system just stay in the assigned
locality?  I haven't read the spec, so maybe that is disallowed.
There is something nice about cleaning up and releasing the locality
when not in use, but it's also causing a problem here.

Regards,
Jason