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]

Message-ID: <2c4a80e0d30bf1dfe89c6e3469d1dbfb008275fa.camel@linux.intel.com>
Date:   Tue, 31 Dec 2019 01:28:36 +0200
From:   Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>
To:     Dan Williams <dan.j.williams@...el.com>,
        Jerry Snitselaar <jsnitsel@...hat.com>
Cc:     Greg KH <gregkh@...uxfoundation.org>,
        Christian Bundy <christianbundy@...ction.io>,
        Jason Gunthorpe <jgg@...pe.ca>,
        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 Sun, 2019-12-29 at 23:41 -0800, Dan Williams wrote:
> 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/

I think for short term, yes, it is better to revert the commits
that make things more broken.

for-linus-v5.5-rc5 branch contains three commits that exactly do
this i.e. the reverts that Stefan sent and revert to Jerry's earlier
commit.

After that is out of the table it is easier to analyze how the code
should be actually refactored. Like, I have no idea when I get
local HW that can reproduce this and Jerry still seems to have the
same issue. It'd be nice make the exactly right changes instead of
reverts but situation is what it is.

Please check the branch and ACK/NAK if I can add tested-by's (and
other tags).

/Jarkko