On Sep 2, 5:12pm, "Sun, Ning" wrote: } Subject: RE: [tboot-devel] reset after GETSEC[SENTER] on redhat platforms
Good afternoon, I hope the end of the week is going well for everyone. > *Intel: https://github.com/01org/TPM2.0-TSS > *TSS2 based tpm2-tools: https://github.com/01org/tpm2.0-tools Yes, we are very familiar with both of those projects. Given they are C++ implementations on top of the TSS reference library they are somewhat more of a formidable body of code to understand, build and deploy, particularly in embedded environments which we focus on. The mileage of others will certainly vary of course. > *IBM: http://sourceforge.net/projects/ibmtpm20tss/ That is the project from Ken Goldman's lab at IBM's TJ Watson facility, that I referenced in my e-mail and that we use as the basis for our TPM2 tooling. It is very complete and very well done. In order to be useful as a tooling support library it benefits from some minor patches to create a versioned shared library and also requires the necessary cohort of include files to be abstracted out into an independent include directory. Ken's lab also has their TPM2 simulator up on Sourceforge and we would strongly recommend that anyone who goes the route of rolling their own tooling from the TSS library get that running to test their code on. We also recommend downloading the four TPM2 reference PDF's (Architecture, Structures, Commands, Supporting Routines) from the TCG's web-site and be prepared to do some reading. Once you get all that running, those who are interested in TPM2 based platforms will want to read and study the Intel TXT Software Development Manual very closely to understand the NVram configuration guidelines and LCPv3 requirements for TPM2 based platforms. The NVram index authorization attribute system is completely different on TPM2 based systems and the tboot distribution only supports the creation of attributes on TPM1.2 based systems. Perhaps most importantly for anyone trying to get past GETSEC[SENTER], based on the documented inheritance relationship between the PS and PO policies it isn't clear that the current tboot policy tool, lcp2_crtpol, will create a valid PO policy on TPM2 based plaforms. If anyone else gets this far you can test this by trying an MLE with and without a PO policy in place. The presence of even the most basic PO policy, ie ANY policy, causes the ACM to reset the platform without any updates to the TXT.ERRCODE register. This may also effect the interpretation of an LCPv3 policy on non-TPM2 based systems, which could be at the root of the hardware resets which are currently under discussion. All of that logic, unfortunately, is in the ACM which has been rather studiously designed to be non-debuggable. Just as a point of general interest, the PCONF policy element completely changes in TPM2 based systems. Is there anyone in the world who has even tried to build and get an ACM to execute a PCONF2 based policy element with a TPMS quote structure imbedded in it? > Regards, > -NIng Have a good weekend. Greg }-- End of excerpt from "Sun, Ning" As always, Dr. G.W. Wettstein, Ph.D. Enjellic Systems Development, LLC. 4206 N. 19th Ave. Specializing in information infra-structure Fargo, ND 58102 development. PH: 701-281-1686 FAX: 701-281-3949 EMAIL: g...@enjellic.com ------------------------------------------------------------------------------ "Five year projections, are you kidding me. We don't know what we are supposed to be doing at the 4 o'clock meeting this afternoon." -- Terry Wieland Resurrection ------------------------------------------------------------------------------ _______________________________________________ tboot-devel mailing list tboot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tboot-devel
