Menu
▾
▴
tboot-devel — Developer support
You can subscribe to this list here.
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(3) |
Dec
(13) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2008 |
Jan
(19) |
Feb
(24) |
Mar
(8) |
Apr
(14) |
May
(8) |
Jun
(10) |
Jul
(14) |
Aug
(3) |
Sep
(13) |
Oct
(27) |
Nov
(39) |
Dec
(24) |
| 2009 |
Jan
(19) |
Feb
(4) |
Mar
(2) |
Apr
(15) |
May
|
Jun
(2) |
Jul
(44) |
Aug
(21) |
Sep
(20) |
Oct
(2) |
Nov
(1) |
Dec
(7) |
| 2010 |
Jan
(7) |
Feb
(10) |
Mar
(2) |
Apr
(12) |
May
(7) |
Jun
(2) |
Jul
(18) |
Aug
(11) |
Sep
(4) |
Oct
(25) |
Nov
(8) |
Dec
(1) |
| 2011 |
Jan
(27) |
Feb
(2) |
Mar
(19) |
Apr
(8) |
May
(16) |
Jun
(11) |
Jul
(9) |
Aug
(9) |
Sep
(35) |
Oct
(9) |
Nov
(8) |
Dec
(32) |
| 2012 |
Jan
(37) |
Feb
(20) |
Mar
(2) |
Apr
(24) |
May
(4) |
Jun
(3) |
Jul
(5) |
Aug
(21) |
Sep
(8) |
Oct
(15) |
Nov
(1) |
Dec
(7) |
| 2013 |
Jan
(4) |
Feb
(8) |
Mar
(38) |
Apr
(9) |
May
(42) |
Jun
(4) |
Jul
(21) |
Aug
(4) |
Sep
|
Oct
(7) |
Nov
(2) |
Dec
(3) |
| 2014 |
Jan
(8) |
Feb
(8) |
Mar
(5) |
Apr
(9) |
May
(19) |
Jun
(1) |
Jul
(10) |
Aug
(25) |
Sep
(6) |
Oct
(2) |
Nov
(5) |
Dec
(1) |
| 2015 |
Jan
|
Feb
|
Mar
(5) |
Apr
|
May
(12) |
Jun
|
Jul
(2) |
Aug
(5) |
Sep
(11) |
Oct
(5) |
Nov
(3) |
Dec
(1) |
| 2016 |
Jan
(2) |
Feb
(24) |
Mar
|
Apr
(6) |
May
(26) |
Jun
(20) |
Jul
(8) |
Aug
(15) |
Sep
(21) |
Oct
(1) |
Nov
(7) |
Dec
(24) |
| 2017 |
Jan
(12) |
Feb
(2) |
Mar
(6) |
Apr
(8) |
May
(18) |
Jun
(13) |
Jul
(12) |
Aug
(8) |
Sep
(5) |
Oct
(1) |
Nov
|
Dec
|
| 2018 |
Jan
(2) |
Feb
(12) |
Mar
(8) |
Apr
(5) |
May
(7) |
Jun
(1) |
Jul
(4) |
Aug
(8) |
Sep
(2) |
Oct
(3) |
Nov
(4) |
Dec
(3) |
| 2019 |
Jan
(8) |
Feb
|
Mar
(2) |
Apr
|
May
(3) |
Jun
(4) |
Jul
(1) |
Aug
|
Sep
(8) |
Oct
(6) |
Nov
(20) |
Dec
(14) |
| 2020 |
Jan
(25) |
Feb
(12) |
Mar
(2) |
Apr
(13) |
May
(44) |
Jun
(9) |
Jul
|
Aug
(3) |
Sep
(5) |
Oct
(4) |
Nov
(2) |
Dec
|
| 2021 |
Jan
(6) |
Feb
|
Mar
(7) |
Apr
(1) |
May
|
Jun
(2) |
Jul
|
Aug
(16) |
Sep
(4) |
Oct
(6) |
Nov
(1) |
Dec
(6) |
| 2022 |
Jan
(5) |
Feb
(4) |
Mar
(22) |
Apr
(6) |
May
(4) |
Jun
(17) |
Jul
(2) |
Aug
|
Sep
|
Oct
(2) |
Nov
(1) |
Dec
(2) |
| 2023 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2024 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2025 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Jun K. <jun...@gm...> - 2008-02-15 03:29:09
|
On 2/15/08, Cihula, Joseph <jos...@in...> wrote: > On Thursday, February 14, 2008 3:30 AM, Jun Koi wrote: > > Hi, > > > > I am enjoying reading the tboot source code. I found that one of the > > first steps of tboot is to check some TPM functions. However, I dont > > understand the idea behind some tests, like in the function > > tpm_unit_test_before_senter(). > > > > Joseph, could you explain a bit about the motivation of those tests? > > > The various test routines were used to validate that the TPM code was > working correctly. Is it necessary to do the test? Or we can suppose that if machine supports SINIT insn, TPM would work flawlessly? Or did you see some malfunction TPM already? Thanks, Jun |
|
From: Cihula, J. <jos...@in...> - 2008-02-14 18:28:18
|
On Thursday, February 14, 2008 3:30 AM, Jun Koi wrote: > Hi, > > I am enjoying reading the tboot source code. I found that one of the > first steps of tboot is to check some TPM functions. However, I dont > understand the idea behind some tests, like in the function > tpm_unit_test_before_senter(). > > Joseph, could you explain a bit about the motivation of those tests? The various test routines were used to validate that the TPM code was working correctly. They are not actually invoked by default and require that TPM_UNIT_TEST be defined in order to be compiled in. The current code has actually moved all of this test code into a test-patches directory to make the regular code easier to read. We felt that it was useful to keep these tests as part of the distribution so that we could re-validate the code if we needed to make some changes and so that others could benefit by seeing what and how it was tested. > > Many thanks, > Jun > > ------------------------------------------------------------------------ - > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > tboot-devel mailing list > tbo...@li... > https://lists.sourceforge.net/lists/listinfo/tboot-devel |
|
From: Jun K. <jun...@gm...> - 2008-02-14 11:30:21
|
Hi, I am enjoying reading the tboot source code. I found that one of the first steps of tboot is to check some TPM functions. However, I dont understand the idea behind some tests, like in the function tpm_unit_test_before_senter(). Joseph, could you explain a bit about the motivation of those tests? Many thanks, Jun |
|
From: Hiroshi I. <his...@an...> - 2008-02-11 22:31:22
|
Hi all, I have a very similar problem which David posted on Jan 14. Sorry for making a new thread, I just joined this mailing list. The problem was the system reboots when GETSEC[SENTER] is executed. Even if I set policy into TPM NVRAM, it still reboots. I am using infineon TPM chip (version 1.2.1.0). I made changes to the source code along with the patch Hal posted on Jan 2 because I originally had the same problem. My question is about the serial logs which David and Hal posted. I found these logs in the very beginning of the each log. TBOOT: TPM: get capability, return value = 00000000 TBOOT: TPM: get nvindex size, return value = 00000000 OR TBOOT: TPM: get capability, return value = 00000003 TBOOT: TPM: get nvindex size, return value = 00000003 Although I checked the latest version of TBOOT source code (tboot-20071128.tar.gz), I could not find the above lines. Which version are you using? I don' know this is a critical issue, but I just wanted to make sure that I am using the correct version of code. Kindest regards, Hiroshi Isozaki |
|
From: Kuniyasu S. <k.s...@ai...> - 2008-02-08 02:39:25
|
Joe,
>>From: "Cihula, Joseph" <jos...@in...>
>>Subject: RE: [tboot-devel] TPM driver on DQ35JO Motherboard
>>
>>> >>It seems to work fine on the DQ35JO platform from Fedora 8.
>>> >>What error(s) are you getting?
>>>
>>> Unfortunately tpm doesn't work well.
>>> I installed TrouSerS 0.3.1 and tpm-tools 1.3.1 on Fedora 8(2.6.23).
>>
>>This TPM does not have an EK already provisioned, so you need to create
>>one before you can take ownership. Use the tpm_createek command from
>>tpm-tools. Then you should be able to take ownership.
Thank you. I can take ownership on Fedora 8(2.6.23) on DQ35JO.
The log is as following.
# /sbin/modprobe tpm_tis interrupts=0 force=1
# /usr/sbin/tcsd
# /usr/sbin/tpm_createek
# /usr/sbin/tpm_takeownership
Enter owner password:
Confirm password:
Enter SRK password:
Confirm password:
P.S.
I also confirm the operation of TPM on our TrustedComutingGeeks-Knoppix (2.6.19)
which we released yesterday. :-)
http://unit.aist.go.jp/itri/knoppix/index-en.html
I confirm the operation of Linux-IMA(Integrity Measurement Architecture)
kernel and TPM-Manager.
I have to add the following options at GRUB-IMA menu.
tpm_tis.force=1 tpm_tis.interrupts-0 acpi=off
# Please ignore the message from GRUB-IMA.
Unfortunately I have to add "acpi=off" option and I'm afraid tboot don't work well.
------
suzaki
|
|
From: Cihula, J. <jos...@in...> - 2008-02-07 18:20:59
|
On Thursday, February 07, 2008 3:08 AM, Kuniyasu Suzaki wrote: > Joe, > > >>From: "Cihula, Joseph" <jos...@in...> > >>Subject: RE: [tboot-devel] TPM driver on DQ35JO Motherboard > >> > >>> Do you mean Linux 2.6.23 and the tpm driver work well on DQ35JO > >>(TPM:WinBond)? > >>> I would like to try on Debian. :-) > >> > >>It seems to work fine on the DQ35JO platform from Fedora 8. > >>What error(s) are you getting? > > Unfortunately tpm doesn't work well. > I installed TrouSerS 0.3.1 and tpm-tools 1.3.1 on Fedora 8(2.6.23). > > I could install driver but the takeownership was faild. > > # /sbin/modprobe tpm_tis interrupts=0 force=1 > # /usr/sbin/tcsd > # /usr/sbin/tpm_takeownership > Enter owner password: > Confirm password: > Enter SRK password: > Confirm password: > Tspi_TPM_TakeOwnership failed: 0x00000023 - layer=tpm, code=0023 (35), No EK This TPM does not have an EK already provisioned, so you need to create one before you can take ownership. Use the tpm_createek command from tpm-tools. Then you should be able to take ownership. > > I could get tpm vesion. > > # /usr/sbin/tpm_version > TPM 1.2 Version Info: > Chip Version: 1.2.2.16 > Spec Level: 2 > Errata Revision: 1 > TPM Vendor ID: WEC > TPM Version: 01010000 > Manufacturer Info: 57454300 > > ----- > suzaki > > >> > >>> > >>> ------ > >>> suzaki > >>> > >>> >>From: "Cihula, Joseph" <jos...@in...> > >>> >>Subject: RE: [tboot-devel] TPM driver on DQ35JO Motherboard > >>> >> > >>> >>I've used Fedora 8 and the TPM driver works fine. Sometimes you > >>need to > >>> >>load it as 'modprobe tpm_tis interrupts=0 force=1'--can you see if > >>this > >>> >>works for you? > >>> >> > >>> >>Joe > >>> >> > >>> >>-----Original Message----- > >>> >>From: tbo...@li... > >>> >>[mailto:tbo...@li...] On Behalf Of > >>Kuniyasu > >>> >>Suzaki > >>> >>Sent: Tuesday, February 05, 2008 5:34 PM > >>> >>To: tbo...@li... > >>> >>Subject: [tboot-devel] TPM driver on DQ35JO Motherboard > >>> >> > >>> >> > >>> >>Dear, > >>> >> > >>> >>Please tell me how to set up TPM-driver on DQ35JO motherboard. > >>> >> http://www.intel.com/products/motherboard/DQ35JO/index.htm > >>> >> > >>> >>Native tpm_tis.ko for Linux 2.6.22 did not work well. > >>> >>I want to try tboot on DQ35JO motherboard. > >>> >> > >>> >>------ > >>> >>suzaki > >>> >> > >>> >> > >>> >> > >>> > >>>>-------------------------------------------------------------------- -- > >>-- > >>> >>- > >>> >>This SF.net email is sponsored by: Microsoft > >>> >>Defy all challenges. Microsoft(R) Visual Studio 2008. > >>> >>http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > >>> >>_______________________________________________ > >>> >>tboot-devel mailing list > >>> >>tbo...@li... > >>> >>https://lists.sourceforge.net/lists/listinfo/tboot-devel |
|
From: Kuniyasu S. <k.s...@ai...> - 2008-02-07 11:08:28
|
Joe, >>From: "Cihula, Joseph" <jos...@in...> >>Subject: RE: [tboot-devel] TPM driver on DQ35JO Motherboard >> >>> Do you mean Linux 2.6.23 and the tpm driver work well on DQ35JO >>(TPM:WinBond)? >>> I would like to try on Debian. :-) >> >>It seems to work fine on the DQ35JO platform from Fedora 8. >>What error(s) are you getting? Unfortunately tpm doesn't work well. I installed TrouSerS 0.3.1 and tpm-tools 1.3.1 on Fedora 8(2.6.23). I could install driver but the takeownership was faild. # /sbin/modprobe tpm_tis interrupts=0 force=1 # /usr/sbin/tcsd # /usr/sbin/tpm_takeownership Enter owner password: Confirm password: Enter SRK password: Confirm password: Tspi_TPM_TakeOwnership failed: 0x00000023 - layer=tpm, code=0023 (35), No EK I could get tpm vesion. # /usr/sbin/tpm_version TPM 1.2 Version Info: Chip Version: 1.2.2.16 Spec Level: 2 Errata Revision: 1 TPM Vendor ID: WEC TPM Version: 01010000 Manufacturer Info: 57454300 ----- suzaki >> >>> >>> ------ >>> suzaki >>> >>> >>From: "Cihula, Joseph" <jos...@in...> >>> >>Subject: RE: [tboot-devel] TPM driver on DQ35JO Motherboard >>> >> >>> >>I've used Fedora 8 and the TPM driver works fine. Sometimes you >>need to >>> >>load it as 'modprobe tpm_tis interrupts=0 force=1'--can you see if >>this >>> >>works for you? >>> >> >>> >>Joe >>> >> >>> >>-----Original Message----- >>> >>From: tbo...@li... >>> >>[mailto:tbo...@li...] On Behalf Of >>Kuniyasu >>> >>Suzaki >>> >>Sent: Tuesday, February 05, 2008 5:34 PM >>> >>To: tbo...@li... >>> >>Subject: [tboot-devel] TPM driver on DQ35JO Motherboard >>> >> >>> >> >>> >>Dear, >>> >> >>> >>Please tell me how to set up TPM-driver on DQ35JO motherboard. >>> >> http://www.intel.com/products/motherboard/DQ35JO/index.htm >>> >> >>> >>Native tpm_tis.ko for Linux 2.6.22 did not work well. >>> >>I want to try tboot on DQ35JO motherboard. >>> >> >>> >>------ >>> >>suzaki >>> >> >>> >> >>> >> >>> >>>>---------------------------------------------------------------------- >>-- >>> >>- >>> >>This SF.net email is sponsored by: Microsoft >>> >>Defy all challenges. Microsoft(R) Visual Studio 2008. >>> >>http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >>> >>_______________________________________________ >>> >>tboot-devel mailing list >>> >>tbo...@li... >>> >>https://lists.sourceforge.net/lists/listinfo/tboot-devel >> |
|
From: Cihula, J. <jos...@in...> - 2008-02-07 07:29:04
|
On Wednesday, February 06, 2008 12:03 AM, Kuniyasu Suzaki wrote: > Hello, Joe, > > Do you mean Linux 2.6.23 and the tpm driver work well on DQ35JO (TPM:WinBond)? > I would like to try on Debian. :-) It seems to work fine on the DQ35JO platform from Fedora 8. What error(s) are you getting? Joe > > ------ > suzaki > > >>From: "Cihula, Joseph" <jos...@in...> > >>Subject: RE: [tboot-devel] TPM driver on DQ35JO Motherboard > >> > >>I've used Fedora 8 and the TPM driver works fine. Sometimes you need to > >>load it as 'modprobe tpm_tis interrupts=0 force=1'--can you see if this > >>works for you? > >> > >>Joe > >> > >>-----Original Message----- > >>From: tbo...@li... > >>[mailto:tbo...@li...] On Behalf Of Kuniyasu > >>Suzaki > >>Sent: Tuesday, February 05, 2008 5:34 PM > >>To: tbo...@li... > >>Subject: [tboot-devel] TPM driver on DQ35JO Motherboard > >> > >> > >>Dear, > >> > >>Please tell me how to set up TPM-driver on DQ35JO motherboard. > >> http://www.intel.com/products/motherboard/DQ35JO/index.htm > >> > >>Native tpm_tis.ko for Linux 2.6.22 did not work well. > >>I want to try tboot on DQ35JO motherboard. > >> > >>------ > >>suzaki > >> > >> > >> > >>---------------------------------------------------------------------- -- > >>- > >>This SF.net email is sponsored by: Microsoft > >>Defy all challenges. Microsoft(R) Visual Studio 2008. > >>http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > >>_______________________________________________ > >>tboot-devel mailing list > >>tbo...@li... > >>https://lists.sourceforge.net/lists/listinfo/tboot-devel |
|
From: David D. <tro...@gm...> - 2008-02-06 19:15:46
|
On my Dell Optiplex 755, I can only define 4 indices. When I try to define
a fifth one, I get:
Tspi_NV_DefineSpace failed: Insufficient TPM resources
Command DefIndex failed:
TSS API failed
Does anyone else have this problem?
I have trousers 0.3.1 and tpm-tools 1.3.0 installed.
Here's some info about my TPM:
TPM 1.2 Version Info:
Chip Version: 1.2.4.30
Spec Level: 2
Errata Revision: 2
TPM Vendor ID: STM
TPM Version: 01010000
Manufacturer Info: 53544d20
TPM_PERMANENT_FLAGS:
disable: FALSE
ownership: TRUE
deactivated: FALSE
readPubek: FALSE
disableOwnerClear: FALSE
allowMaintenance: TRUE
physicalPresenceLifetimeLock: TRUE
physicalPresenceHWEnable: TRUE
physicalPresenceCMDEnable: FALSE
CEKPUsed: FALSE
TPMpost: FALSE
TPMpostLock: FALSE
FIPS: TRUE
Operator: FALSE
enableRevokeEK: FALSE
nvLocked: FALSE
readSRKPub: FALSE
tpmEstablished: FALSE
maintenanceDone: FALSE
TPM_STCLEAR_FLAGS:
deactivated: FALSE
disableForceClear: FALSE
physicalPresence: TRUE
physicalPresenceLock: FALSE
bGlobalLock: FALSE
Thanks,
David
|
|
From: Kuniyasu S. <k.s...@ai...> - 2008-02-06 08:02:55
|
Hello, Joe, Do you mean Linux 2.6.23 and the tpm driver work well on DQ35JO (TPM:WinBond)? I would like to try on Debian. :-) ------ suzaki >>From: "Cihula, Joseph" <jos...@in...> >>Subject: RE: [tboot-devel] TPM driver on DQ35JO Motherboard >> >>I've used Fedora 8 and the TPM driver works fine. Sometimes you need to >>load it as 'modprobe tpm_tis interrupts=0 force=1'--can you see if this >>works for you? >> >>Joe >> >>-----Original Message----- >>From: tbo...@li... >>[mailto:tbo...@li...] On Behalf Of Kuniyasu >>Suzaki >>Sent: Tuesday, February 05, 2008 5:34 PM >>To: tbo...@li... >>Subject: [tboot-devel] TPM driver on DQ35JO Motherboard >> >> >>Dear, >> >>Please tell me how to set up TPM-driver on DQ35JO motherboard. >> http://www.intel.com/products/motherboard/DQ35JO/index.htm >> >>Native tpm_tis.ko for Linux 2.6.22 did not work well. >>I want to try tboot on DQ35JO motherboard. >> >>------ >>suzaki >> >> >> >>------------------------------------------------------------------------ >>- >>This SF.net email is sponsored by: Microsoft >>Defy all challenges. Microsoft(R) Visual Studio 2008. >>http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >>_______________________________________________ >>tboot-devel mailing list >>tbo...@li... >>https://lists.sourceforge.net/lists/listinfo/tboot-devel >> |
|
From: Cihula, J. <jos...@in...> - 2008-02-06 05:24:06
|
I've used Fedora 8 and the TPM driver works fine. Sometimes you need to load it as 'modprobe tpm_tis interrupts=0 force=1'--can you see if this works for you? Joe -----Original Message----- From: tbo...@li... [mailto:tbo...@li...] On Behalf Of Kuniyasu Suzaki Sent: Tuesday, February 05, 2008 5:34 PM To: tbo...@li... Subject: [tboot-devel] TPM driver on DQ35JO Motherboard Dear, Please tell me how to set up TPM-driver on DQ35JO motherboard. http://www.intel.com/products/motherboard/DQ35JO/index.htm Native tpm_tis.ko for Linux 2.6.22 did not work well. I want to try tboot on DQ35JO motherboard. ------ suzaki ------------------------------------------------------------------------ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ tboot-devel mailing list tbo...@li... https://lists.sourceforge.net/lists/listinfo/tboot-devel |
|
From: Kuniyasu S. <k.s...@ai...> - 2008-02-06 01:34:26
|
Dear, Please tell me how to set up TPM-driver on DQ35JO motherboard. http://www.intel.com/products/motherboard/DQ35JO/index.htm Native tpm_tis.ko for Linux 2.6.22 did not work well. I want to try tboot on DQ35JO motherboard. ------ suzaki |
|
From: Hal F. <hal...@gm...> - 2008-01-16 18:48:09
|
On Jan 16, 2008 5:49 AM, David Dorsey <tro...@gm...> wrote: > That's weird. When I try to enable OS management of Embedded Security > Device I get "This feature cannot be changed while "Trusted Execution > Technology" feature is enabled. So I tried turning off TXT, enabling OS > management, and then turning TXT on again... This BIOS then disabled that > feature. Hmmm, I recall experiencing something similar when I was trying to initially enable the various options. I'm not sure how I got it turned on now. Anyway, I don't think it is important. I disabled it and tboot still launches just fine. > What version of the BIOS do you have? >From the System Information screen in BIOS, it is "786F1 v01.04". I also ran tpm_version from the CVS tpm-tools and it had the same output you reported. Did you patch tboot/common/tpm.c in order to get past the timeout problems I reported? Did you perhaps make any other patches to tboot? One other change I made, probably not important, is that I disabled the "trousers" target in the main tboot Makefile. I already have Trousers from trousers.sf.net CVS head installed and running, and it has the NV support needed by tboot. Hal |
|
From: David D. <tro...@gm...> - 2008-01-16 13:49:19
|
That's weird. When I try to enable OS management of Embedded Security Device I get "This feature cannot be changed while "Trusted Execution Technology" feature is enabled. So I tried turning off TXT, enabling OS management, and then turning TXT on again... This BIOS then disabled that feature. What version of the BIOS do you have? David On Jan 15, 2008 3:19 PM, Hal Finney <hal...@gm...> wrote: > Hi David - I guess that attachment did not come through here - were > you able to see the log I attached last night? > > These machines have only been out for a few weeks so I doubt that > there is any significant difference between our two machines, although > I have only 1 GB while you have 2. > > Here are some of my BIOS setups, perhaps some of these are relevant: > > Under System Security: > > Data Execution Prevention: Enable > Virtualization Technology (VTx): Enable > Virtualization Technology Directed I/O (VTd): Enable > Trusted Execution Technology: Enable > Embedded Security Device Support: Enable > Reset to Factory Settings: Do not reset > Power-On Authentication Support: Disable > Reset authentication credential: Do not reset > OS management of Embedded Security Device: Enable > Reset of Embedded Security Device through OS: Disable > > The other one that I think is relevant is under Advanced/Device Options: > > Multi-Processor: Enable > > Previously there have been reports that tboot would not launch if > multi-processors are disabled in the BIOS. > > Anyway see if any of these settings are different - > > Hal > |
|
From: Hal F. <hal...@gm...> - 2008-01-15 22:19:39
|
Hi David - I guess that attachment did not come through here - were you able to see the log I attached last night? These machines have only been out for a few weeks so I doubt that there is any significant difference between our two machines, although I have only 1 GB while you have 2. Here are some of my BIOS setups, perhaps some of these are relevant: Under System Security: Data Execution Prevention: Enable Virtualization Technology (VTx): Enable Virtualization Technology Directed I/O (VTd): Enable Trusted Execution Technology: Enable Embedded Security Device Support: Enable Reset to Factory Settings: Do not reset Power-On Authentication Support: Disable Reset authentication credential: Do not reset OS management of Embedded Security Device: Enable Reset of Embedded Security Device through OS: Disable The other one that I think is relevant is under Advanced/Device Options: Multi-Processor: Enable Previously there have been reports that tboot would not launch if multi-processors are disabled in the BIOS. Anyway see if any of these settings are different - Hal |
|
From: David D. <tro...@gm...> - 2008-01-15 18:46:29
|
Just realized I didn't send this out to the list...
Ah... now I have TPM envy. :o)
Just doubled checked. I am using the latest release version of SINIT.
David
On Jan 15, 2008 11:32 AM, Cihula, Joseph <jos...@in...> wrote:
> David,
>
> Bit 0 in the TPM access reg just indicates whether a dynamic launch had
> ever been done on that TPM. Hal's indicates that his did, and yours that it
> has not. This is not important to SENTER working (and once it does work,
> yours will show 0x81 as well ;-).
>
> Are you sure that you're using the release version of SINIT (i.e. the one
> on the tboot SourceForge site)?
>
> Joe
>
> ------------------------------
> *From:* David Dorsey [mailto:tro...@gm...]
> *Sent:* Tuesday, January 15, 2008 10:17 AM
> *To:* Hal Finney
> *Cc:* Cihula, Joseph; Wei, Gang; tbo...@li...
> *Subject:* Re: [tboot-devel] Infineon TPM problems and fixes
>
> Hal,
>
> I've attached a log where there is no policy. It reboots after
> GETSEC[SENTER]. I've compared my log to yours and I noticed that the TPM
> Access reg content was different. Yours returns 0x80 and mine returns
> 0x81. I don't know if that would make any big differences though.
>
> Also, what TPM version do you have. Here's the output of the tpm_version
> command for me:
>
> TPM 1.2 Version Info:
> Chip Version: 1.2.1.2
> Spec Level: 2
> Errata Revision: 0
> TPM Vendor ID: IFX
> TPM Version: 01010000
> Manufacturer Info: 4946580
>
>
> David
>
>
> On Jan 14, 2008 9:10 PM, David Dorsey <tro...@gm...> wrote:
>
> > Hal,
> >
> > Yes, in the log I included I have a policy set. But I've also tried it
> > with no policy set and it still fails. I didn't post that since I didn't
> > think it would add any value.
> >
> >
> > David
> >
> >
> >
> > On Jan 14, 2008 7:02 PM, Hal Finney <hal...@gm...> wrote:
> >
> > > It looks to me like you do have a policy set, David:
> > >
> > > 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
> > >
> > > You might want to use tpmnv_relindex -i 20000001 to delete this entry
> > > from the TPM.
> > >
> > > I have attached a log of what a successful tboot launch looks like on
> > > my system -
> > >
> > > Hal
> > >
> >
> >
>
|
|
From: Cihula, J. <jos...@in...> - 2008-01-15 18:34:03
|
David,
=20
Bit 0 in the TPM access reg just indicates whether a dynamic launch had
ever been done on that TPM. Hal's indicates that his did, and yours
that it has not. This is not important to SENTER working (and once it
does work, yours will show 0x81 as well ;-).
=20
Are you sure that you're using the release version of SINIT (i.e. the
one on the tboot SourceForge site)?
=20
Joe
________________________________
From: David Dorsey [mailto:tro...@gm...]=20
Sent: Tuesday, January 15, 2008 10:17 AM
To: Hal Finney
Cc: Cihula, Joseph; Wei, Gang; tbo...@li...
Subject: Re: [tboot-devel] Infineon TPM problems and fixes
=09
=09
Hal,
=09
I've attached a log where there is no policy. It reboots after
GETSEC[SENTER]. I've compared my log to yours and I noticed that the
TPM Access reg content was different. Yours returns 0x80 and mine
returns 0x81. I don't know if that would make any big differences
though.=20
=09
Also, what TPM version do you have. Here's the output of the
tpm_version command for me:
=09
TPM 1.2 Version Info:=20
Chip Version: 1.2.1.2=20
Spec Level: 2=20
Errata Revision: 0=20
TPM Vendor ID: IFX=20
TPM Version: 01010000=20
Manufacturer Info: 4946580=20
=09
=09
David
=09
=09
=09
On Jan 14, 2008 9:10 PM, David Dorsey <tro...@gm...>
wrote:
=09
Hal,
=09
Yes, in the log I included I have a policy set. But
I've also tried it with no policy set and it still fails. I didn't post
that since I didn't think it would add any value.
=09
=09
David=20
On Jan 14, 2008 7:02 PM, Hal Finney
<hal...@gm...> wrote:
=09
It looks to me like you do have a policy set,
David:
=09
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=20
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=20
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}}=20
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
=09
=09
You might want to use tpmnv_relindex -i 20000001
to delete this entry=20
from the TPM.
=09
I have attached a log of what a successful tboot
launch looks like on
my system -
=09
Hal
=09
|
|
From: David D. <tro...@gm...> - 2008-01-15 18:17:12
|
Hal,
I've attached a log where there is no policy. It reboots after
GETSEC[SENTER]. I've compared my log to yours and I noticed that the TPM
Access reg content was different. Yours returns 0x80 and mine returns
0x81. I don't know if that would make any big differences though.
Also, what TPM version do you have. Here's the output of the tpm_version
command for me:
TPM 1.2 Version Info:
Chip Version: 1.2.1.2
Spec Level: 2
Errata Revision: 0
TPM Vendor ID: IFX
TPM Version: 01010000
Manufacturer Info: 4946580
David
On Jan 14, 2008 9:10 PM, David Dorsey <tro...@gm...> wrote:
> Hal,
>
> Yes, in the log I included I have a policy set. But I've also tried it
> with no policy set and it still fails. I didn't post that since I didn't
> think it would add any value.
>
>
> David
>
>
>
> On Jan 14, 2008 7:02 PM, Hal Finney <hal...@gm...> wrote:
>
> > It looks to me like you do have a policy set, David:
> >
> > 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
> >
> > You might want to use tpmnv_relindex -i 20000001 to delete this entry
> > from the TPM.
> >
> > I have attached a log of what a successful tboot launch looks like on
> > my system -
> >
> > Hal
> >
>
>
|
|
From: David D. <tro...@gm...> - 2008-01-15 04:10:49
|
Hal,
Yes, in the log I included I have a policy set. But I've also tried it with
no policy set and it still fails. I didn't post that since I didn't think
it would add any value.
David
On Jan 14, 2008 7:02 PM, Hal Finney <hal...@gm...> wrote:
> It looks to me like you do have a policy set, David:
>
> 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
>
> You might want to use tpmnv_relindex -i 20000001 to delete this entry
> from the TPM.
>
> I have attached a log of what a successful tboot launch looks like on
> my system -
>
> Hal
>
|
|
From: Hal F. <hal...@gm...> - 2008-01-15 02:02:14
|
It looks to me like you do have a policy set, David:
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
You might want to use tpmnv_relindex -i 20000001 to delete this entry
from the TPM.
I have attached a log of what a successful tboot launch looks like on
my system -
Hal
|
|
From: Cihula, J. <jos...@in...> - 2008-01-14 21:05:47
|
David,
=20
Do you also get a failure if you don't set any policy (e.g. delete the
one you have now)? And when you say that it "also does this with the
default policy", which policy (index) is this and what are its contents
(you can get that from lcp_readpol)?
=20
Joe
________________________________
From: David Dorsey [mailto:tro...@gm...]=20
Sent: Monday, January 14, 2008 9:03 AM
To: Cihula, Joseph
Cc: Wei, Gang; Hal Finney; tbo...@li...
Subject: Re: [tboot-devel] Infineon TPM problems and fixes
=09
=09
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
=09
I've included the console log.
=09
Thanks,
=09
David
=09
=09
TBOOT: ***************************************=20
TBOOT: begin launch()=20
TBOOT: TPM is ready=20
TBOOT: TPM: Access reg content: 0x81=20
TBOOT: TPM: wait for cmd ready .=20
TBOOT: TPM: get capability, return value =3D 00000000=20
TBOOT: TPM: get nvindex size, return value =3D 00000000=20
TBOOT: TPM: Access reg content: 0x81=20
TBOOT: TPM: wait for cmd ready .=20
TBOOT: TPM: read nv index 20000001 from offset 00000000, return
value =3D 00000000=20
TBOOT: TPM: Access reg content: 0x81=20
TBOOT: TPM: wait for cmd ready .=20
TBOOT: TPM: read nv index 20000001 from offset 00000100, return
value =3D 00000000=20
TBOOT: tb_policy_index:=20
TBOOT: version =3D 1=20
TBOOT: policy_type =3D 0=20
TBOOT: num_policies =3D 2=20
TBOOT: policy[0]:=20
TBOOT: uuid =3D {0x756a5bfe, 0x5b0b, 0x4d33, 0xb867,=20
{0xd7, 0x83, 0xfb, 0x46, 0x36, 0xbf}}=20
TBOOT: hash_alg =3D 0=20
TBOOT: hash_type =3D 1=20
TBOOT: num_hashes =3D 1=20
TBOOT: hashes[0] =3D 67 8a 89 be 3f 5d db ae 93 b4 fe b9
bb ba 3d 27 de 92 a=20
TBOOT: policy[1]:=20
TBOOT: uuid =3D {0x894c909f, 0xd614, 0x4625, 0x8a2d,=20
{0x45, 0x3b, 0x80, 0x10, 0xca, 0x8c}}=20
TBOOT: hash_alg =3D 0=20
TBOOT: hash_type =3D 1=20
TBOOT: num_hashes =3D 1=20
TBOOT: hashes[0] =3D e7 a2 26 58 55 69 67 18 34 dc c4 58
2f 16 33 36 1f f9 0=20
TBOOT: TPM: Access reg content: 0x81=20
TBOOT: TPM: wait for cmd ready .=20
TBOOT: TPM: write nv 20000002, offset 00000000, 00000004 bytes,
return =3D 00000000=20
TBOOT: succeeded.=20
TBOOT: IA32_FEATURE_CONTROL_MSR: 0000ff07=20
TBOOT: CPU is SMX-capable=20
TBOOT: CPU is VMX-capable=20
TBOOT: SMX is enabled=20
TBOOT: TXT chipset and all needed capabilities present=20
TBOOT: bios_os_data (@7df20008, 24):=20
TBOOT: version=3D2=20
TBOOT: bios_sinit_size=3D0=20
TBOOT: lcp_pd_base=3D0=20
TBOOT: lcp_pd_size=3D0=20
TBOOT: num_logical_procs=3D2=20
TBOOT: TPM: Access reg content: 0x81=20
TBOOT: TPM: wait for cmd ready .=20
TBOOT: TPM: write nv 20000002, offset 00000000, 00000004 bytes,
return =3D 00000000=20
TBOOT: succeeded.=20
TBOOT: LT.ERRORCODE=3D0=20
TBOOT: LT.ESTS=3D0=20
TBOOT: CR0.NE not set=20
TBOOT: CR0 and EFLAGS OK=20
TBOOT: no machine check errors=20
TBOOT: CPU is ready for SENTER=20
TBOOT: checking previous errors on the last boot.=20
TPM: Access reg content: 0x81=20
TBOOT: TPM: wait for cmd ready .=20
TBOOT: TPM: read nv index 20000002 from offset 00000000, return
value =3D 00000000=20
TBOOT: last boot has error.=20
TBOOT: user-provided SINIT found:
/BRLK_SINIT_20070910_release.BIN=20
TBOOT: chipset ids: vendor=3D8086, device=3D8001, revision=3D7=20
TBOOT: 1 ACM chipset id entries:=20
TBOOT: vendor=3D8086, device=3D8001, flags=3D1, revision=3D7,
extended=3D0=20
TBOOT: copied SINIT (size=3D5f00) to 7df00000=20
TBOOT: AC mod base alignment OK=20
TBOOT: AC mod size OK=20
TBOOT: AC module header dump for SINIT:=20
TBOOT: type=3D2=20
TBOOT: length=3Da1=20
TBOOT: version=3D0=20
TBOOT: id=3D29c0=20
TBOOT: vendor=3D8086=20
TBOOT: date=3D20070910=20
TBOOT: size*4=3D5f00=20
TBOOT: entry point=3D00000008:00003f5a=20
TBOOT: scratch_size=3D8f=20
TBOOT: info_table:=20
TBOOT: uuid=3D{0x8024d6cd, 0x4733, 0x2a62, 0xf1d1,=20
{0x3a, 0x89, 0x3b, 0x11, 0x82, 0xbc}}=20
TBOOT: chipset_acm_type=3D1=20
TBOOT: version=3D2=20
TBOOT: length=3D20=20
TBOOT: chipset_id_list=3D4e0=20
TBOOT: os_sinit_data_ver=3D3=20
TBOOT: mle_hdr_ver=3D10001=20
TBOOT: file addresses:=20
TBOOT: &_start=3D01003000=20
TBOOT: &_end=3D01033000=20
TBOOT: &_mle_start=3D01003000=20
TBOOT: &_mle_end=3D01018000=20
TBOOT: &__start=3D01003020=20
TBOOT: &_txt_wakeup=3D01003110=20
TBOOT: &g_mle_hdr=3D01012680=20
TBOOT: MLE header:=20
TBOOT: guid=3D{0x9082ac5a, 0x476f, 0x74a7, 0x5c0f,=20
{0x55, 0xa2, 0xcb, 0x51, 0xb6, 0x42}}=20
TBOOT: length=3D28=20
TBOOT: version=3D00010001=20
TBOOT: entry_point=3D00000020=20
TBOOT: first_valid_page=3D00000000=20
TBOOT: mle_start_off=3D0=20
TBOOT: mle_end_off=3D15000=20
TBOOT: MLE start=3D1003000, end=3D1018000, size=3D15000=20
TBOOT: ptab_size=3D3000, ptab_base=3D01000000=20
TBOOT: bios_os_data (@7df20008, 24):=20
TBOOT: version=3D2=20
TBOOT: bios_sinit_size=3D0=20
TBOOT: lcp_pd_base=3D0=20
TBOOT: lcp_pd_size=3D0=20
TBOOT: num_logical_procs=3D2=20
TBOOT: SINIT supports os_sinit_data version 3=20
TBOOT: max_ram=3D7dcafe00=20
TBOOT: no LCP manifest found=20
TBOOT: os_sinit_data (@7df2014c, 58):=20
TBOOT: version=3D3=20
TBOOT: mle_ptab=3D1000000=20
TBOOT: mle_size=3D15000=20
TBOOT: mle_hdr_base=3Df680=20
TBOOT: vtd_pmr_lo_base=3D1000000=20
TBOOT: vtd_pmr_lo_size=3D200000=20
TBOOT: vtd_pmr_hi_base=3D0=20
TBOOT: vtd_pmr_hi_size=3D0=20
TBOOT: lcp_po_base=3D0=20
TBOOT: lcp_po_size=3D0=20
TBOOT: setting MTRRs for acmod: base=3D7df00000, size=3D5f00,
num_pages=3D6=20
TBOOT: executing GETSEC[SENTER]...=20
=09
=09
=09
On Jan 8, 2008 4:32 PM, Cihula, Joseph <jos...@in...>
wrote:
=09
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=20
>> 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.
>
>>
>> First, in tpm_wait_cmd_ready() the code expects the
sts_valid bit in=20
>> 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=20
>> 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=20
>> 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.=20
=09
=09
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=20
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=20
within TIMEOUT_C after the last data cycle is received.
=09
>> Then, I got timeouts in tpm_write_cmd_fifo(), "wait
for data
>> available timeout". This timeout happens after
sending the command to=20
>> 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=20
>> 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=20
>> 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=20
> workaround so far. We may need a better timing
mechanism in TBOOT for
> timeout.
=09
=09
Timeouts can be determined by calling TPM_GetCapability,
TPM_CAP_PROPERTY/TPM_CAP_PROP_TIS_TIMEOUT. From the PC
Client TPM Spec=20
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.
=09
>> 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,=20
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=20
> issue and give us a chance to record your contribution
to TBOOT
project?
>
>>
>> Hal Finney
>>
>
> Jimmy
>
>
=09
------------------------------------------------------------------------
-
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
>
=09
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
=09
=09
------------------------------------------------------------------------
-=20
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
=09
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketp
lace
_______________________________________________
tboot-devel mailing list
tbo...@li...=20
https://lists.sourceforge.net/lists/listinfo/tboot-devel
=09
|
|
From: David D. <tro...@gm...> - 2008-01-14 20:32:13
|
It fails without setting any policy. That's what I meant when I said the
default policy. I used that phrase since tboot uses that phrase when it
can't find the policy index in the tpm.
David
On Jan 14, 2008 1:23 PM, Cihula, Joseph <jos...@in...> wrote:
> David,
>
> Do you also get a failure if you don't set any policy (e.g. delete the one
> you have now)? And when you say that it "also does this with the default
> policy", which policy (index) is this and what are its contents (you can
> get that from lcp_readpol)?
>
> Joe
>
> ------------------------------
> *From:* David Dorsey [mailto:tro...@gm...]
> *Sent:* Monday, January 14, 2008 9:03 AM
> *To:* Cihula, Joseph
> *Cc:* Wei, Gang; Hal Finney; tbo...@li...
> *Subject:* Re: [tboot-devel] Infineon TPM problems and fixes
>
> 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
> >
>
>
|
|
From: Cihula, J. <jos...@in...> - 2008-01-14 20:22:04
|
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
|
|
From: Hal F. <hal...@gm...> - 2008-01-14 19:18:53
|
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.
I have successfully launched the tboot SENTER code, so when I get back
home I will try comparing your log with what I get.
Hal Finney
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?
>
> 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
> >
>
>
|
|
From: David D. <tro...@gm...> - 2008-01-14 17:02:51
|
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
>
|
15 messages has been excluded from this view by a project administrator.
