linux-kernel - Re: [PATCH v2] tpm_tis: reserve chip for duration of tpm_tis_core

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: <20191219100747.fhbqmzk7xby3tt3l@cantor>
Date:   Thu, 19 Dec 2019 03:07:47 -0700
From:   Jerry Snitselaar <jsnitsel@...hat.com>
To:     Dan Williams <dan.j.williams@...el.com>
Cc:     Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Christian Bundy <christianbundy@...ction.io>,
        Peter Huewe <peterhuewe@....de>,
        Jason Gunthorpe <jgg@...pe.ca>,
        Stefan Berger <stefanb@...ux.vnet.ibm.com>,
        stable <stable@...r.kernel.org>, linux-integrity@...r.kernel.org
Subject: Re: [PATCH v2] tpm_tis: reserve chip for duration of
 tpm_tis_core_init

On Wed Dec 18 19, Dan Williams wrote:
>On Wed, Dec 18, 2019 at 3:07 PM Jarkko Sakkinen
><jarkko.sakkinen@...ux.intel.com> wrote:
>>
>> On Tue, 2019-12-17 at 10:18 -0700, Jerry Snitselaar wrote:
>> > On Tue Dec 17 19, Jarkko Sakkinen wrote:
>> > > On Mon, 2019-12-16 at 18:14 -0800, Dan Williams wrote:
>> > > > On Mon, Dec 16, 2019 at 6:00 PM Jerry Snitselaar <jsnitsel@...hat.com> wrote:
>> > > > > On Mon Dec 16 19, Dan Williams wrote:
>> > > > > > On Mon, Dec 16, 2019 at 4:59 PM Jarkko Sakkinen
>> > > > > > <jarkko.sakkinen@...ux.intel.com> wrote:
>> > > > > > > On Wed, 2019-12-11 at 16:54 -0700, Jerry Snitselaar wrote:
>> > > > > > > > Instead of repeatedly calling tpm_chip_start/tpm_chip_stop when
>> > > > > > > > issuing commands to the tpm during initialization, just reserve the
>> > > > > > > > chip after wait_startup, and release it when we are ready to call
>> > > > > > > > tpm_chip_register.
>> > > > > > > >
>> > > > > > > > Cc: Christian Bundy <christianbundy@...ction.io>
>> > > > > > > > Cc: Dan Williams <dan.j.williams@...el.com>
>> > > > > > > > Cc: Peter Huewe <peterhuewe@....de>
>> > > > > > > > Cc: Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>
>> > > > > > > > Cc: Jason Gunthorpe <jgg@...pe.ca>
>> > > > > > > > Cc: Stefan Berger <stefanb@...ux.vnet.ibm.com>
>> > > > > > > > Cc: stable@...r.kernel.org
>> > > > > > > > Cc: linux-integrity@...r.kernel.org
>> > > > > > > > Fixes: a3fbfae82b4c ("tpm: take TPM chip power gating out of tpm_transmit()")
>> > > > > > > > Fixes: 5b359c7c4372 ("tpm_tis_core: Turn on the TPM before probing IRQ's")
>> > > > > > > > Signed-off-by: Jerry Snitselaar <jsnitsel@...hat.com>
>> > > > > > >
>> > > > > > > I pushed to my master with minor tweaks and added my tags.
>> > > > > > >
>> > > > > > > Please check before I put it to linux-next.
>> > > > > >
>> > > > > > I don't see it yet here:
>> > > > > >
>> > > > > > http://git.infradead.org/users/jjs/linux-tpmdd.git/shortlog/refs/heads/master
>> > > > > >
>> > > > > > However, I wanted to make sure you captured that this does *not* fix
>> > > > > > the interrupt issue. I.e. make sure you remove the "Fixes:
>> > > > > > 5b359c7c4372 ("tpm_tis_core: Turn on the TPM before probing IRQ's")"
>> > > > > > tag.
>> > > > > >
>> > > > > > With that said, are you going to include the revert of:
>> > > > > >
>> > > > > > 1ea32c83c699 tpm_tis_core: Set TPM_CHIP_FLAG_IRQ before probing for interrupts
>> > > > >
>> > > > > Dan, with the above reverted do you still get the screaming interrupt?
>> > > >
>> > > > Yes, the screaming interrupt goes away, although it is replaced by
>> > > > these messages when the driver starts:
>> > > >
>> > > > [    3.725131] tpm_tis IFX0740:00: 2.0 TPM (device-id 0x1B, rev-id 16)
>> > > > [    3.725358] tpm tpm0: tpm_try_transmit: send(): error -5
>> > > > [    3.725359] tpm tpm0: [Firmware Bug]: TPM interrupt not working,
>> > > > polling instead
>> > > >
>> > > > If the choice is "error message + polled-mode" vs "pinning a cpu with
>> > > > interrupts" I'd accept the former, but wanted Jarkko with his
>> > > > maintainer hat to weigh in.
>> > > >
>> > > > Is there a simple sanity check I can run to see if the TPM is still
>> > > > operational in this state?
>> > >
>> > > What about T490S?
>> > >
>> > > /Jarkko
>> > >
>> >
>> > Hi Jarkko, I'm waiting to hear back from the t490s user, but I imagine
>> > it still has the problem as well.
>> >
>> > Christian, were you able to try this patch and verify it still
>> > resolves the issue you were having with the kernel failing to get the
>> > timeouts and durations from the tpm?
>>
>> Including those reverts would be a bogus change at this point.
>
>I'm failing to see how you arrived at that conclusion.
>
>> The fix that I already applied obviously fixes an issue even if
>> it does not fix all the issues.
>
>These patches take a usable system and make it unusable:
>
>1ea32c83c699 tpm_tis_core: Set TPM_CHIP_FLAG_IRQ before probing for interrupts
>5b359c7c4372 tpm_tis_core: Turn on the TPM before probing IRQ's
>
>...they need to be reverted, or the regression needs to be fixed, but
>asserting that you fixed something else unrelated does not help.
>

Reverting 1ea32c83c699 ("tpm_tis_core: Set TPM_CHIP_FLAG_IRQ before
probing for interrupts") would at least allow people impacted by this
to boot their systems without disabling the tpm, or blacklisting the
module while we figure this out. From what I can tell the tpm_tis code
was operating in that state since 570a36097f30 ("tpm: drop 'irq' from
struct tpm_vendor_specific") until Stefan's patch.

Regards,
Jerry