linux-kernel - Re: Patch "tpm_tis: reserve chip for duration of tpm_tis_core_init" has been added to the 5.4-stable tree

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] [thread-next>] [day] [month] [year] [list]

Date:   Sun, 29 Dec 2019 23:41:56 -0800
From:   Dan Williams <dan.j.williams@...el.com>
To:     Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>
Cc:     Greg KH <gregkh@...uxfoundation.org>,
        Christian Bundy <christianbundy@...ction.io>,
        Jason Gunthorpe <jgg@...pe.ca>,
        Jerry Snitselaar <jsnitsel@...hat.com>,
        Peter Huewe <peterhuewe@....de>,
        Stefan Berger <stefanb@...ux.vnet.ibm.com>,
        stable-commits@...r.kernel.org, linux-integrity@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Patch "tpm_tis: reserve chip for duration of tpm_tis_core_init"
 has been added to the 5.4-stable tree

On Sat, Dec 28, 2019 at 9:17 AM Dan Williams <dan.j.williams@...el.com> wrote:
>
> On Sat, Dec 28, 2019 at 7:15 AM Jarkko Sakkinen
> <jarkko.sakkinen@...ux.intel.com> wrote:
> >
> > On Fri, Dec 27, 2019 at 08:11:50AM +0200, Jarkko Sakkinen wrote:
> > > Dan, please also test the branch and tell if other patches are needed.
> > > I'm a bit blind with this as I don't have direct access to the faulting
> > > hardware. Thanks. [*]
> > >
> > > [*] https://lkml.org/lkml/2019/12/27/12
> >
> > Given that:
> >
> > 1. I cannot reproduce the bug locally.
> > 2. Neither of the patches have any appropriate tags (tested-by and
> >    reviewed-by). [*]
> >
> > I'm sorry but how am I expected to include these patches?
>
> Thanks for the branch, I'll get it tested on the failing hardware.
> Might be a few days due to holiday lag.

This looked like the wrong revert to me, and testing confirms that
this does not fix the problem.

As I mentioned in the original report [1] the commit that bisect flagged was:

    5b359c7c4372 tpm_tis_core: Turn on the TPM before probing IRQ's

That commit moved tpm_chip_start() before irq probing. Commit
21df4a8b6018 "tpm_tis: reserve chip for duration of tpm_tis_core_init"
does not appear to change anything in that regard.

Perhaps this hardware has always had broken interrupts and needs to be
quirked off? I'm trying an experiment with tpm_tis_core.interrupts=0
workaround.


[1]: https://lore.kernel.org/linux-integrity/CAA9_cmeLnHK4y+usQaWo72nUG3RNsripuZnS-koY4XTRC+mwJA@mail.gmail.com/