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 <joseph.cihula@intel.com> 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
> tboot-devel@lists.sourceforge.net
> 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
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel