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

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

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?

I've included the console log.

Thanks,

David

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 = 00000000
TBOOT: TPM: get nvindex size, return value = 00000000
TBOOT: TPM: Access reg content: 0x81
TBOOT: TPM: wait for cmd ready .
TBOOT: TPM: read nv index 20000001 from offset 00000000, return value =
00000000
TBOOT: TPM: Access reg content: 0x81
TBOOT: TPM: wait for cmd ready .
TBOOT: TPM: read nv index 20000001 from offset 00000100, return value =
00000000
TBOOT: tb_policy_index:
TBOOT:   version = 1
TBOOT:   policy_type = 0
TBOOT:   num_policies = 2
TBOOT:   policy[0]:
TBOOT:           uuid = {0x756a5bfe, 0x5b0b, 0x4d33, 0xb867,
                {0xd7, 0x83, 0xfb, 0x46, 0x36, 0xbf}}
TBOOT:           hash_alg = 0
TBOOT:           hash_type = 1
TBOOT:           num_hashes = 1
TBOOT:           hashes[0] = 67 8a 89 be 3f 5d db ae 93 b4 fe b9 bb ba 3d 27
de 92 a
TBOOT:   policy[1]:
TBOOT:           uuid = {0x894c909f, 0xd614, 0x4625, 0x8a2d,
                {0x45, 0x3b, 0x80, 0x10, 0xca, 0x8c}}
TBOOT:           hash_alg = 0
TBOOT:           hash_type = 1
TBOOT:           num_hashes = 1
TBOOT:           hashes[0] = 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 =
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=2
TBOOT:   bios_sinit_size=0
TBOOT:   lcp_pd_base=0
TBOOT:   lcp_pd_size=0
TBOOT:   num_logical_procs=2
TBOOT: TPM: Access reg content: 0x81
TBOOT: TPM: wait for cmd ready .
TBOOT: TPM: write nv 20000002, offset 00000000, 00000004 bytes, return =
00000000
TBOOT: succeeded.
TBOOT: LT.ERRORCODE=0
TBOOT: LT.ESTS=0
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 =
00000000
TBOOT: last boot has error.
TBOOT: user-provided SINIT found: /BRLK_SINIT_20070910_release.BIN
TBOOT: chipset ids: vendor=8086, device=8001, revision=7
TBOOT: 1 ACM chipset id entries:
TBOOT:  vendor=8086, device=8001, flags=1, revision=7, extended=0
TBOOT: copied SINIT (size=5f00) to 7df00000
TBOOT: AC mod base alignment OK
TBOOT: AC mod size OK
TBOOT: AC module header dump for SINIT:
TBOOT:   type=2
TBOOT:   length=a1
TBOOT:   version=0
TBOOT:   id=29c0
TBOOT:   vendor=8086
TBOOT:   date=20070910
TBOOT:   size*4=5f00
TBOOT:   entry point=00000008:00003f5a
TBOOT:   scratch_size=8f
TBOOT:   info_table:
TBOOT:           uuid={0x8024d6cd, 0x4733, 0x2a62, 0xf1d1,
                {0x3a, 0x89, 0x3b, 0x11, 0x82, 0xbc}}
TBOOT:           chipset_acm_type=1
TBOOT:           version=2
TBOOT:           length=20
TBOOT:           chipset_id_list=4e0
TBOOT:           os_sinit_data_ver=3
TBOOT:           mle_hdr_ver=10001
TBOOT: file addresses:
TBOOT:   &_start=01003000
TBOOT:   &_end=01033000
TBOOT:   &_mle_start=01003000
TBOOT:   &_mle_end=01018000
TBOOT:   &__start=01003020
TBOOT:   &_txt_wakeup=01003110
TBOOT:   &g_mle_hdr=01012680
TBOOT: MLE header:
TBOOT:   guid={0x9082ac5a, 0x476f, 0x74a7, 0x5c0f,
                {0x55, 0xa2, 0xcb, 0x51, 0xb6, 0x42}}
TBOOT:   length=28
TBOOT:   version=00010001
TBOOT:   entry_point=00000020
TBOOT:   first_valid_page=00000000
TBOOT:   mle_start_off=0
TBOOT:   mle_end_off=15000
TBOOT: MLE start=1003000, end=1018000, size=15000
TBOOT: ptab_size=3000, ptab_base=01000000
TBOOT: bios_os_data (@7df20008, 24):
TBOOT:   version=2
TBOOT:   bios_sinit_size=0
TBOOT:   lcp_pd_base=0
TBOOT:   lcp_pd_size=0
TBOOT:   num_logical_procs=2
TBOOT: SINIT supports os_sinit_data version 3
TBOOT: max_ram=7dcafe00
TBOOT: no LCP manifest found
TBOOT: os_sinit_data (@7df2014c, 58):
TBOOT:   version=3
TBOOT:   mle_ptab=1000000
TBOOT:   mle_size=15000
TBOOT:   mle_hdr_base=f680
TBOOT:   vtd_pmr_lo_base=1000000
TBOOT:   vtd_pmr_lo_size=200000
TBOOT:   vtd_pmr_hi_base=0
TBOOT:   vtd_pmr_hi_size=0
TBOOT:   lcp_po_base=0
TBOOT:   lcp_po_size=0
TBOOT: setting MTRRs for acmod: base=7df00000, size=5f00, num_pages=6
TBOOT: executing GETSEC[SENTER]...

On Jan 8, 2008 4:32 PM, Cihula, Joseph <jos...@in...> wrote:

> On Monday, January 07, 2008 6:04 PM, Wei, Gang wrote:
> > Hal Finney <> scribbled on 2008-01-03 06:37 AM:
> >
> >> 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.
> >
> > Hal, thank you very much for your experimenting to figure out &
> resolve
> > TPM related issues in current TBOOT code.
> >
> >>
> >> 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.
> >
> > 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.
> >
> > 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!
> >
> > 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?
> >
> >>
> >> Hal Finney
> >>
> >
> > Jimmy
> >
> >
> ------------------------------------------------------------------------
> -
> > 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
>
> -------------------------------------------------------------------------
> 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/marketplace
> _______________________________________________
> tboot-devel mailing list
> tbo...@li...
> https://lists.sourceforge.net/lists/listinfo/tboot-devel
>