linux-kernel - Re: patch tpm-correct-tpm-timeouts-to-jiffies-conversion.patch breaks stuff

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

Message-ID: <ea8d860a0807111508m74d92fbep84306c80753bf591@mail.gmail.com>
Date:	Sat, 12 Jul 2008 00:08:34 +0200
From:	"Marcin Obara" <marcin_obara@...rs.sourceforge.net>
To:	Valdis.Kletnieks@...edu
Cc:	"Andrew Morton" <akpm@...ux-foundation.org>,
	"Marcel Selhorst" <tpm@...horst.net>,
	"Kylene Jo Hall" <kjhall@...ibm.com>, linux-kernel@...r.kernel.org
Subject: Re: patch tpm-correct-tpm-timeouts-to-jiffies-conversion.patch breaks stuff

2008/7/11  <Valdis.Kletnieks@...edu>:
> With tpm-correct-tpm-timeouts-to-jiffies-conversion.patch reverted, I
> get -ETIME errors from libtpm2.0/utils/tpm_demo:
>
> With the patch in place, the first read dies horribly, as reported by
> strace -T -r utils/tpm_demo:
>
> 0.000969 open("/dev/tpm0", O_RDWR) = 3 <0.000080>
> 0.000237 write(3, "\0\301\0\0\0\22\0\0\0e\0\0\0\6\0\0\0\0", 18) = 18 <0.012652>
> 0.012814 read(3, 0x7fffd26cd430, 4096) = -1 ETIME (Timer expired) <0.000068>
> 0.000168 close(3)                  = 0 <0.000041>
> 0.000132 exit_group(-1)            = ?
>
> Note that the write() call took 0.012 seconds, but the read() was hit with
> a -ETIME after only 0.000068 seconds, so it's obviously too short.
Not exactly.
read() call only returns result of already done TPM transmission.
All TPM transmission is done in write() call.
Transmission contains 3 timeoutable operations connected with timeout values:
- timeout 2 (_b) = 2000000 =  2 sec
      in    tpm_tis.c:tpm_tis_send():
           if (wait_for_stat
                   (chip, TPM_STS_COMMAND_READY, chip->vendor.timeout_b,
                    &chip->vendor.int_queue) < 0) {
                       rc = -ETIME;
- for ordinal = 0xe0 - duration TPM_SHORT = 1000 = 0,001 sec
      in    tpm_tis.c:tpm_tis_send():
           if (wait_for_stat
                   (chip, TPM_STS_DATA_AVAIL | TPM_STS_VALID,
                    tpm_calc_ordinal_duration(chip, ordinal),
                    &chip->vendor.read_queue) < 0) {
                       rc = -ETIME;

- timeout 3 (_c) = 750000 = 0,75 sec
      in tmp_tis.c:recv_data():
             wait_for_stat(chip,
                            TPM_STS_DATA_AVAIL | TPM_STS_VALID,
                            chip->vendor.timeout_c,
                            &chip->vendor.read_queue)

So for this example, we have timeouts:
- 2 sec   (timeout_b)
- 0,001 sec    (TPM_SHORT)
- 0,75 sec  (timeout_c)
Transaction time was
 0,013 sec  ( > 0.001)
write() call response would be at least 0,75 sec if failed on
timeout_b or timeout_c.
It looks like duration TPM_SHORT = 1000 returned by your Broadcom chip
is too short (=wrong).

> Dumping the raw values in the 'data + TPM_GET_CAP_mumble' I see:
>
> [ 2170.060661] timeout 1 = 750000
> [ 2170.060866] timeout 2 = 2000000
> [ 2170.060994] timeout 3 = 750000
> [ 2170.061119] timeout 4 = 750000
> [ 2170.072437] raw durations are 1000 2000000 120000000
>
> (all values are before application of foo_to_jiffies)
>
> So is the spec wrong, or is my chipset on drugs, or?

So your chipset is on drugs.

It's strange range of returned timeouts/durations:
0,75 / 2 / 0,75 / 0,75  (sec)
0,001  / 2 / 120 (sec)

With reversed patch timeouts would be:
12,5 min / 33 min / 12,5 min / 12,5 min
1 sec / ~33 min / ~33 hours!!!!
I can not event imagine TPM driver hanging for over 1 day on one write() call .

In my opinion Broadcom 0102 TPM chip is broken.

Regards
Marcin
--
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/