linux-kernel - [PATCH 0/1] tpm_tis: handle -EPROBE_DEFER in tpm_tis_plat

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

Message-Id: <20210205202022.4515-1-dirk@gouders.net>
Date:   Fri,  5 Feb 2021 21:20:21 +0100
From:   Dirk Gouders <dirk@...ders.net>
To:     Peter Huewe <peterhuewe@....de>,
        Jarkko Sakkinen <jarkko@...nel.org>,
        Jason Gunthorpe <jgg@...pe.ca>
Cc:     Dirk Gouders <dirk@...ders.net>,
        James Bottomley <James.Bottomley@...senPartnership.com>,
        linux-integrity@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: [PATCH 0/1] tpm_tis: handle -EPROBE_DEFER in tpm_tis_plat_probe()

Hello,

I noticed that the tpm_tis driver behaves different depending on
wether it was compiled builtin or as a module.

At least on my hardware, if builtin it always falls back to polling mode
without notification which I do not understand considering the current
efforts to fix interrupt probing[1].

The builtin case could be fixed by handling -EPROBE_DEFER.  With a
temporary dev_dbg() call added and James Bottomley's
"[PATCH v2 4/5] tpm_tis: fix IRQ probing [1]" applied my kernel log
looks like this:

[    2.671629] tpm_tis STM0125:00: Waiting for interrupt...
[    2.851920] tpm_tis STM0125:00: Waiting for interrupt...
[    2.852627] tpm_tis STM0125:00: Waiting for interrupt...
[    2.908286] tpm_tis STM0125:00: Waiting for interrupt...
[    3.340223] tpm_tis STM0125:00: Waiting for interrupt...
[    3.407238] tpm_tis STM0125:00: Waiting for interrupt...
[    3.408178] tpm_tis STM0125:00: Waiting for interrupt...
[    3.408994] tpm_tis STM0125:00: Waiting for interrupt...
[    3.487694] tpm_tis STM0125:00: Waiting for interrupt...
[    3.773769] tpm_tis STM0125:00: Waiting for interrupt...
[    3.868590] tpm_tis STM0125:00: Waiting for interrupt...
[    3.923855] tpm_tis STM0125:00: Waiting for interrupt...
[    4.235670] tpm_tis STM0125:00: Waiting for interrupt...
[    4.852556] tpm_tis STM0125:00: Waiting for interrupt...
[    6.767544] tpm_tis STM0125:00: 2.0 TPM (device-id 0x0, rev-id 78)
[    6.767567] tpm_tis STM0125:00: TPM interface capabilities (0x30000415):
[    6.767569] tpm_tis STM0125:00: 	Interrupt Level Low
[    6.767570] tpm_tis STM0125:00: 	Locality Change Int Support
[    6.767570] tpm_tis STM0125:00: 	Data Avail Int Support


Of course, this patch should not be added before Jarkko's fix [2], because
builtin drivers would then hit the WARN_ONCE(), as well.

Dirk


[1] https://lore.kernel.org/linux-integrity/20201001180925.13808-5-James.Bottomley@HansenPartnership.com/
[2] https://lore.kernel.org/linux-integrity/3936843b-c0da-dd8c-8aa9-90aa3b49d525@linux.ibm.com/T/#t

Dirk Gouders (1):
  tpm_tis: handle -EPROBE_DEFER in tpm_tis_plat_probe()

 drivers/char/tpm/tpm_tis.c | 3 +++
 1 file changed, 3 insertions(+)

-- 
2.26.2