I also do not understand why this was causing a freeze, but this change does seem to make the issue go away. At the very least, something along the lines of the patch is the correct thing to do anyways.
I ran "tpm_version" from tpm-tools against the TPM that I spent the most time debugging on and it reported the following: Chip Version: 1.2.41.1 Spec Level: 2 Errata Revision: 3 TPM Vendor ID: ATML TPM Version: 01010000 Manufacturer Info: 41544d4c If there is anything else I can do to get you more information about the TPM itself then just let me know. It would be nice if someone else could reproduce the freeze problem. What I was seeing is that tboot would appear to freeze during the tpm_read_reg() call to check that the commandReady status bit was set after the tpm_write_reg(). I found this rebuilding with custom print statements. When I turned on TPM_TRACE then it would usually work, so I originally thought it was a timing issue. But after reading the spec a little and looking at the code, all I could find as a potential problem was the register size issue. Thanks, Brent On 03/10/2015 03:39 AM, Wei, Gang wrote: > On Mar 10, 2015 05:30, Brent Collins wrote: >> All, >> >> I have been having trouble with a couple of different pieces of hardware >> freezing during the tboot initialization and spent some time figuring >> out what was wrong. >> >> For reference, I was using tboot-1.8.1 as provided by the CentOS >> distribution and having problems with: >> 1. Dell Latitude e6540 laptop >> 2. Dell Venue 7140 >> >> I have found an issue with how tboot handles writing/reading the status >> registers while trying to handle both the TPM 1.2 and 2.0 cases. The >> definition of the status register is always 4 bytes long(as defined in >> "tboot/common/tpm.c", however TPM 1.2 devices still only have a 3 byte >> register. This causes writes/reads to access memory that they should not >> be accessing when communicating with 1.2 versioned TPMs. >> >> I implemented a potential fix which has solved the problem for me on my >> hardware. Basically, I just create 2 different structures for the status >> register and use one or the other based on which type of TPM is present. >> >> I have attached a patch which corrects the problem in a very >> straightforward manner as a reference point. > First of all, thanks for trouble shooting effort on tboot issue and providing > patch to fix it. > > It really surprising me that read/write to the undefined tpm1.2 register > address(0x1b) will cause hardware freezing. Do you know the TPM model used in > the systems? > > But anyway, your patch looks clean to me, we will try to apply it after more > tests. > > Thanks > Jimmy > ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ tboot-devel mailing list tboot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tboot-devel
