linux-kernel - Re: [tpmdd-devel] TPM drivers support and Linux Integrity Module for 2.6.30

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: <4A367093.6010206@linux.vnet.ibm.com>
Date:	Mon, 15 Jun 2009 13:02:27 -0300
From:	Rajiv Andrade <srajiv@...ux.vnet.ibm.com>
To:	Eric Paris <eparis@...hat.com>
CC:	"dds (☕)" <dds@...gle.com>,
	seiji.munetoh@...il.com, tpmdd-devel@...ts.sourceforge.net,
	Mimi Zohar <zohar@...ux.vnet.ibm.com>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Shahbaz Khan <shaz.linux@...il.com>
Subject: Re: [tpmdd-devel] TPM drivers support and Linux Integrity Module
 for 2.6.30

Eric Paris wrote:
> On Sun, 2009-06-14 at 16:20 -0300, Rajiv Andrade wrote:
>   
>> Hi David,
>>
>> On Sun, 2009-06-14 at 16:15 +0900, dds (☕) wrote:
>>     
>>> Hello, I'd been meaning to write about this.
>>>       
>
> I can't seem to find the mail from david in any archive, does anyone
> have a pointer?
>
>   
Neither do I, only have it in my inbox, seems that it got bounced by
both ML..
> but my real problem is that the patch doesn't work!  We call tpm_getcap
> to know if we should work around a tpm bug.
>
> tpm_getcap->transmit_cmd->tpm_transmit->chip->vendor.send
>
> which of course ends up in tpm_tis_send() but we needed that
> manufacturer_id before tpm_tis_send can work!
>
>   
Yep, sorry. Two options:

1- Inside that check, if got an error when in that particular
tpm_getcap() stacked call, consider that it might be this iTPM, and
bypass it just to get the value from the chip (would happen only once) -
Would work, but it's odd.

2- Forget manufacturer_id and base the decision on the PNP_ID as david
suggested. I previously considered it but since it would end up in
modifying tpm_tis_init() prototype (struct device * to struct pnp_dev *)
and then wouldn't work when loading as a module with force option on, so
I moved to the manufacturer_id approach.

I'll get back to #2 meanwhile and post the patch, seems not hard to
accomplish though..
> Below is my dmesg output of a failed build.
>
> [root@...p231-142 ~]# dmesg | grep -i tpm
> [    0.945438] Platform driver 'tpm_tis' needs updating - please use dev_pm_ops
> [    0.951161] tpm_tis tpm_tis: 1.2 TPM (device-id 0x1020, rev-id 6)
> [    0.957171] tpm_tis tpm_tis: tpm_transmit: tpm_send: error -5
> [    0.963239] tpm_tis tpm_tis: tpm_transmit: tpm_send: error -5
> [    0.969190] tpm_tis tpm_tis: tpm_transmit: tpm_send: error -5
> [    0.975165] tpm_tis tpm_tis: tpm_transmit: tpm_send: error -5
> [    0.975369] tpm_tis_init: chip->manufacturer_id=0
> [    1.097287] tpm_tis tpm_tis: tpm_transmit: tpm_send: error -5
> [    1.097445] No TPM chip found, activating TPM-bypass!
> [  110.859305] tpm_tis tpm_tis: tpm_transmit: tpm_send: error -5
>
> See all the failed tpm calls before we set the manufacturer_id at time
> 0.975369?  (that printk is my own addition in tpm_tis_init)
>
> But at least you know the manucaturer_id if it helps...
>
>   
For now it does, thanks

Rajiv
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/