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

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Hal and David,

Can you try reporting the issue of the reboot failure to HP?  They
should support these types of issues, even if they have to dig a bit to
root cause them.

Joe

On Monday, January 14, 2008 11:19 AM, Hal Finney wrote:
> Hi David - I too have the problem that GETSEC failures do not lead to
> a clean reboot. The BIOS goes through its self test and then hangs.
> The only way to get the machine booted up is to power cycle it, which
> clears the ERRORCODE register and leaves no clue as to what went
> wrong. It is enormously frustrating (I have been trying to write my
> own MLE launcher). I wish HP would fix this. I haven't tried reporting
> it because it is such a technical issue that I wonder how they could
> possibly respond.
>=20
> I have successfully launched the tboot SENTER code, so when I get back
> home I will try comparing your log with what I get.
>=20
> Hal Finney
>=20
> On Jan 14, 2008 9:02 AM, David Dorsey <tro...@gm...> wrote:
>> I'm not sure if this is a related issue or not, but I have a HP
dc7800 as
>> well and I'm trying to get tboot to work.  I successfully created the
policy
>> set by following the instructions in the docs folder.  However, when
tboot
>> calls SENTER, the machine just reboots.  The BIOS hangs so I can't
read the
>> error code.  It also does this with the default policy.  Any ideas to
what
>> the problem is or if there any BIOS settings I missed?
>>=20
>> I've included the console log.
>>=20
>> Thanks,
>>=20
>> David
>>=20
>>=20
>> TBOOT: ***************************************
>> TBOOT: begin launch()
>> TBOOT: TPM is ready
>> TBOOT: TPM: Access reg content: 0x81
>> TBOOT: TPM: wait for cmd ready .
>> TBOOT: TPM: get capability, return value =3D 00000000
>> TBOOT: TPM: get nvindex size, return value =3D 00000000
>> TBOOT: TPM: Access reg content: 0x81
>> TBOOT: TPM: wait for cmd ready .
>> TBOOT: TPM: read nv index 20000001 from offset 00000000, return value
=3D
>> 00000000 TBOOT: TPM: Access reg content: 0x81
>> TBOOT: TPM: wait for cmd ready .
>> TBOOT: TPM: read nv index 20000001 from offset 00000100, return value
=3D
>> 00000000 TBOOT: tb_policy_index:
>> TBOOT:   version =3D 1
>> TBOOT:   policy_type =3D 0
>> TBOOT:   num_policies =3D 2
>> TBOOT:   policy[0]:
>> TBOOT:           uuid =3D {0x756a5bfe, 0x5b0b, 0x4d33, 0xb867,
>>                 {0xd7, 0x83, 0xfb, 0x46, 0x36, 0xbf}}
>> TBOOT:           hash_alg =3D 0
>> TBOOT:           hash_type =3D 1
>> TBOOT:           num_hashes =3D 1
>> TBOOT:           hashes[0] =3D 67 8a 89 be 3f 5d db ae 93 b4 fe b9 bb
ba 3d 27
>> de 92 a TBOOT:   policy[1]:
>> TBOOT:           uuid =3D {0x894c909f, 0xd614, 0x4625, 0x8a2d,
>>                 {0x45, 0x3b, 0x80, 0x10, 0xca, 0x8c}}
>> TBOOT:           hash_alg =3D 0
>> TBOOT:           hash_type =3D 1
>> TBOOT:           num_hashes =3D 1
>> TBOOT:           hashes[0] =3D e7 a2 26 58 55 69 67 18 34 dc c4 58 2f
16 33 36
>> 1f f9 0 TBOOT: TPM: Access reg content: 0x81
>> TBOOT: TPM: wait for cmd ready .
>> TBOOT: TPM: write nv 20000002, offset 00000000, 00000004 bytes,
return =3D
>> 00000000 TBOOT: succeeded.
>> TBOOT: IA32_FEATURE_CONTROL_MSR: 0000ff07
>> TBOOT: CPU is SMX-capable
>> TBOOT: CPU is VMX-capable
>> TBOOT: SMX is enabled
>> TBOOT: TXT chipset and all needed capabilities present
>> TBOOT: bios_os_data (@7df20008, 24):
>> TBOOT:   version=3D2
>> TBOOT:   bios_sinit_size=3D0
>> TBOOT:   lcp_pd_base=3D0
>> TBOOT:   lcp_pd_size=3D0
>> TBOOT:   num_logical_procs=3D2
>> TBOOT: TPM: Access reg content: 0x81
>> TBOOT: TPM: wait for cmd ready .
>> TBOOT: TPM: write nv 20000002, offset 00000000, 00000004 bytes,
return =3D
>> 00000000 TBOOT: succeeded.
>> TBOOT: LT.ERRORCODE=3D0
>> TBOOT: LT.ESTS=3D0
>> TBOOT: CR0.NE not set
>> TBOOT: CR0 and EFLAGS OK
>> TBOOT: no machine check errors
>> TBOOT: CPU is ready for SENTER
>> TBOOT: checking previous errors on the last boot.
>>         TPM: Access reg content: 0x81
>> TBOOT: TPM: wait for cmd ready .
>> TBOOT: TPM: read nv index 20000002 from offset 00000000, return value
=3D
>> 00000000 TBOOT: last boot has error.
>> TBOOT: user-provided SINIT found: /BRLK_SINIT_20070910_release.BIN
>> TBOOT: chipset ids: vendor=3D8086, device=3D8001, revision=3D7
>> TBOOT: 1 ACM chipset id entries:
>> TBOOT:  vendor=3D8086, device=3D8001, flags=3D1, revision=3D7, =
extended=3D0
>> TBOOT: copied SINIT (size=3D5f00) to 7df00000
>> TBOOT: AC mod base alignment OK
>> TBOOT: AC mod size OK
>> TBOOT: AC module header dump for SINIT:
>> TBOOT:   type=3D2
>> TBOOT:   length=3Da1
>> TBOOT:   version=3D0
>> TBOOT:   id=3D29c0
>> TBOOT:   vendor=3D8086
>> TBOOT:   date=3D20070910
>> TBOOT:   size*4=3D5f00
>> TBOOT:   entry point=3D00000008:00003f5a
>> TBOOT:   scratch_size=3D8f
>> TBOOT:   info_table:
>> TBOOT:           uuid=3D{0x8024d6cd, 0x4733, 0x2a62, 0xf1d1,
>>                 {0x3a, 0x89, 0x3b, 0x11, 0x82, 0xbc}}
>> TBOOT:           chipset_acm_type=3D1
>> TBOOT:           version=3D2
>> TBOOT:           length=3D20
>> TBOOT:           chipset_id_list=3D4e0
>> TBOOT:           os_sinit_data_ver=3D3
>> TBOOT:           mle_hdr_ver=3D10001
>> TBOOT: file addresses:
>> TBOOT:   &_start=3D01003000
>> TBOOT:   &_end=3D01033000
>> TBOOT:   &_mle_start=3D01003000
>> TBOOT:   &_mle_end=3D01018000
>> TBOOT:   &__start=3D01003020
>> TBOOT:   &_txt_wakeup=3D01003110
>> TBOOT:   &g_mle_hdr=3D01012680
>> TBOOT: MLE header:
>> TBOOT:   guid=3D{0x9082ac5a, 0x476f, 0x74a7, 0x5c0f,
>>                 {0x55, 0xa2, 0xcb, 0x51, 0xb6, 0x42}}
>> TBOOT:   length=3D28
>> TBOOT:   version=3D00010001
>> TBOOT:   entry_point=3D00000020
>> TBOOT:   first_valid_page=3D00000000
>> TBOOT:   mle_start_off=3D0
>> TBOOT:   mle_end_off=3D15000
>> TBOOT: MLE start=3D1003000, end=3D1018000, size=3D15000
>> TBOOT: ptab_size=3D3000, ptab_base=3D01000000
>> TBOOT: bios_os_data (@7df20008, 24):
>> TBOOT:   version=3D2
>> TBOOT:   bios_sinit_size=3D0
>> TBOOT:   lcp_pd_base=3D0
>> TBOOT:   lcp_pd_size=3D0
>> TBOOT:   num_logical_procs=3D2
>> TBOOT: SINIT supports os_sinit_data version 3
>> TBOOT: max_ram=3D7dcafe00
>> TBOOT: no LCP manifest found
>> TBOOT: os_sinit_data (@7df2014c, 58):
>> TBOOT:   version=3D3
>> TBOOT:   mle_ptab=3D1000000
>> TBOOT:   mle_size=3D15000
>> TBOOT:   mle_hdr_base=3Df680
>> TBOOT:   vtd_pmr_lo_base=3D1000000
>> TBOOT:   vtd_pmr_lo_size=3D200000
>> TBOOT:   vtd_pmr_hi_base=3D0
>> TBOOT:   vtd_pmr_hi_size=3D0
>> TBOOT:   lcp_po_base=3D0
>> TBOOT:   lcp_po_size=3D0
>> TBOOT: setting MTRRs for acmod: base=3D7df00000, size=3D5f00, =
num_pages=3D6
>> TBOOT: executing GETSEC[SENTER]...
>>=20
>>=20
>>=20
>>=20
>> On Jan 8, 2008 4:32 PM, Cihula, Joseph <jos...@in...>
wrote:
>>>=20
>>>=20
>>>=20
>>>=20
>>> 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.
>>>=20
>>> 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.
>>>=20
>>>=20
>>>>> 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.
>>>=20
>>> 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.=20
>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>>>> 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
>>>>=20
>>>
------------------------------------------------------------------------
>>> -
>>>> Check out the new SourceForge.net Marketplace.
>>>> It's the best place to buy or sell services for
>>>> just about anything Open Source.
>>>>=20
>>>
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
>>>=20
>>>
------------------------------------------------------------------------
-
>>>=20
>>> Check out the new SourceForge.net Marketplace.
>>> It's the best place to buy or sell services for
>>> just about anything Open Source.
>>>=20
>>
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