linux-kernel - Re: [PATCH] tpm_tis: Hold locality open during probe

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Tue, 12 Jul 2022 11:29:02 -0400
From:   Jason Andryuk <jandryuk@...il.com>
To:     Jarkko Sakkinen <jarkko@...nel.org>
Cc:     Peter Huewe <peterhuewe@....de>, Jason Gunthorpe <jgg@...pe.ca>,
        Chen Jun <chenjun102@...wei.com>,
        James Bottomley <James.Bottomley@...senpartnership.com>,
        stable@...r.kernel.org, linux-integrity@...r.kernel.org,
        open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] tpm_tis: Hold locality open during probe

On Mon, Jul 11, 2022 at 3:37 PM Jason Andryuk <jandryuk@...il.com> wrote:
>
> On Sun, Jul 10, 2022 at 10:58 PM Jarkko Sakkinen <jarkko@...nel.org> wrote:
> >
> > Can you test against
> >
> > https://lore.kernel.org/linux-integrity/20220629232653.1306735-1-LinoSanfilippo@gmx.de/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@oracle.com/),
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