Re: [tboot-devel] Infineon TPM problems and fixes

[Cihula, J. <jos...@in...>]

On Monday, January 07, 2008 6:04 PM, Wei, Gang wrote:
> Hal Finney <> scribbled on 2008-01-03 06:37 AM:
>=20
>> I tried launching tboot on my HP dc7800 vPro machine which uses an
>> Infineon TPM. It largely worked except that it got timeout errors
>> talking to the TPM. I did quite a bit of experimenting and found that
>> this TPM behaves a little differently than the code expects.
>=20
> Hal, thank you very much for your experimenting to figure out &
resolve
> TPM related issues in current TBOOT code.
>=20
>>=20
>> First, in tpm_wait_cmd_ready() the code expects the sts_valid bit in
>> the STS register to come on. However, this never happens. Apparently
>> Infineon feels that turning on the command_ready bit is enough of a
>> clue that the chip is ready to receive a command. After the first
>> write of data to the FIFO register, the sts_valid and expect bits do
>> come on as expected to indicate that the chip can accept more bytes,
>> but the code doesn't care at that point. I fixed this by patching the
>> code to ignore the failure of the sts_valid bit to appear, and just
>> proceed on.
>=20
> Seem like the Infineon TPM does not fully conform to TCG TPM SPEC, and
> your fix is acceptable.

According to my read of the spec, the stsValid bit does not need to be
set when querying the commandReady bit:
	stsValid
	This bit indicates that both TPM_STS_x.dataAvail and
TPM_STS_x.Expect are correct. If TPM_STS_x.stsValid is not set, then
TPM_STS_x.dataAvail and TPM_STS_x.Expect are not guaranteed to be
correct and software that is using TPM_STS_x.dataAvail or
TPM_STS_x.Expect must poll on TPM_STS_x register until
TPM_STS_x.stsValid is set. The TPM MUST set the TPM_STS_x.stsValid bit
within TIMEOUT_C after the last data cycle is received.

>> Then, I got timeouts in tpm_write_cmd_fifo(),  "wait for data
>> available timeout". This timeout happens after sending the command to
>> the chip and waiting for the response to appear. I notice that the
>> timeout counter, TPM_DATA_AVAIL_TIME_OUT, is only 0x100 which might
be
>> a little low. I increased it to 0x10000 and that fixed it. I didn't
>> take much time to try different values. Some commands like unseal or
>> key load can take a long time with some TPMs, like hundreds of
>> milliseconds; and of course keygen can take a minute or more. So this
>> timer either needs to be a lot bigger in general, or else the code
>> needs to be smart about how long various commands are expected to
>> take.
>=20
> Increasing TPM_DATA_AVAIL_TIME_OUT from 0x100 to 0x10000  can be a
> workaround so far. We may need a better timing mechanism in TBOOT for
> timeout.

Timeouts can be determined by calling TPM_GetCapability,
TPM_CAP_PROPERTY/TPM_CAP_PROP_TIS_TIMEOUT.  From the PC Client TPM Spec
you can then find out what operations each timeout applies to (by
searching).  We can probably use the default value (< 2s), but will need
to map it to the spin loop.

>> So with these two changes the tboot code appeared to work OK. I don't
>> actually have Xen installed so it dies at the end as expected, but it
>> does manage to launch the measured environment, talk to the TPM,
print
>> out and extend the various PCRs, and even seal some data
successfully.
>> It's nice to know that my TXT hardware is in working order!
>=20
> Your are lucky. And could you send out your patch for fixing Infineon
> issue and give us a chance to record your contribution to TBOOT
project?
>=20
>>=20
>> Hal Finney
>>=20
>=20
> Jimmy
>=20
>
------------------------------------------------------------------------
-
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
>
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketp
lace
> _______________________________________________
> tboot-devel mailing list
> tbo...@li...
> https://lists.sourceforge.net/lists/listinfo/tboot-devel