OK, it looks like we are at TPM 1.2. TXT.ERRORCODE: 0xc00010c1
It is a XEON CPU E5 2660 v3 @ 2.60GHZ. It looks like it loads the SINIT / AC module loads from the BIOS. As for chipset: Intel Corporation C610/X99 How do you find the PS and AUX NVRAM index? Also I am not implementing any policies, at least not on purpose. On 09/02/2016 11:12 AM, Sun, Ning wrote: > *Intel: https://github.com/01org/TPM2.0-TSS > *TSS2 based tpm2-tools: https://github.com/01org/tpm2.0-tools > *IBM: http://sourceforge.net/projects/ibmtpm20tss/ > > > Regards, > -NIng > > -----Original Message----- > From: Dr. Greg Wettstein [mailto:g...@wind.enjellic.com] > Sent: Friday, September 02, 2016 6:51 AM > To: Brian E Luckau <bluc...@sgi.com>; 'tboot-devel@lists.sourceforge.net' > <tboot-devel@lists.sourceforge.net> > Subject: Re: [tboot-devel] reset after GETSEC[SENTER] on redhat platforms > > On Sep 1, 5:11pm, Brian E Luckau wrote: > } Subject: Re: [tboot-devel] reset after GETSEC[SENTER] on redhat platforms > >> Hi, > Good morning Brian, I hope your day is starting out well. > > Also greetings to Safayet from GE who I see responded downthread as well. I > will integrate his comments below. > >> Whever we use tboot 1.9.4 on platforms such as RHEL 7.3 beta, or >> CentOS 7.2, with Intel TXT enabled in the BIOS, it reboots constantly >> and the last thing we see before the reboot is: >> >> TBOOT: setting MTRRs for acmod: base=0x7bf00000, size=0x20000, >> num_pages=32 >> TBOOT: The maximum allowed MTRR range size=256 Pages >> TBOOT: executing GETSEC[SENTER]... >> >> In centOS 7.2, if I disable Intel TXT in the BIOS then at least the OS >> is able to boot to completion. >> >> Is this a known issue? > Welcome to SMX development and debugging... :-) > > As Safayet commented, the last line is the tboot hypervisor issueing the > SENTER leaf instruction to initiate execution of the Authenticated Code > Model. Since the ACM is specifically designed to prevent it from being > debugged or examined, the only information available is if the ACM deigns to > place an errorcode in the TXT.ERRCODE SMX register. > > Unfortunately we are tracking a similar problem (ACM platform reset on > GETSEC[SENTER]) where the TXT.ERRCODE register never gets updated, which > gives one virtually nothing to go on. It would be very helpful if you could > get the TXT.ERRCODE value for everyone to look at if it is other then zero, > if it is zero that would be a significant finding in and of itself. > Secondly, could you provide a full description of the platform you are > attempting to implement your MLE on? Hardware vendor, processor family > (Broadwell, Skylake, other et.al), chipset and whether or not the hardware > has a TPM1.2 or a TPM2 chip. It would also be helpful to know the exact name > of the ACM module which you are loading. > > Thirdly, it would be helpful to know if you are implementing a Platform Owner > (PO) Launch Control Policy (LCP) and what version and type of the policy you > are implementing. Based on our reading of the TXT/SDM, the lcp2_crtpol > utility provided with the tboot distribution is not capable of generating a > valid LCPv3 control policy if the ACM is processing it as we believe it > should be. > > If you would like to proceed forward independently on debugging this, check > to see whether the Platform Supplier (PS) and AUX NVRAM ind (PS) and AUX > NVRAM index > ex locations are defined. If you are on a TPM1.2 based system the PS index > should be at 0x50000001 and the AUX will be at 0x50000002 on platforms which > are Ivy Bridge and older and 0x50000003 on platforms after that. If you are > on a TPM2 based system we will be really interested in chatting with you. > > If you have PS and AUX registers defined, delete your PO NVram location and > try booting the system only with the PS and AUX indexes/registers. I believe > the standard practice is for OEM board manufacturers to configure an ANY > policy in the PS index, which doesn't convey any practical security > guarantees but will usually result in a successful MLE. > > Just for the record we have been working for nine months to get a TXT/MLE > working on TPM2 based Broadwell platforms. To spare everyone some anguish > there is no support for manipulating or managing TPM2 based NVram indexes in > the tboot package. We built tooling on top of a library which we created > from the TSE utilities which Ken Goldman's lab at IBM has released. > > We are currently seeing the same system reset on GETSEC[SENTER] which Brian > is reporting. The reset only occurs if a PO policy is supplied, which is > leading us to believe that the ACM processing of an LCPv3 PO policy is > flawed. As I noted above the tboot utilities are not capable of producing a > valid policy, at least according to our read of the documentation. > >> --Brian Luckau > I hope the above information is useful. Be glad that you are not trying to > do SGX development as that is a completely different can of worms.... :-)( > > We will be interested in your findings. > > Have a good holiday wekeend. > > Greg > > }-- End of excerpt from Brian E Luckau > > 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 > ------------------------------------------------------------------------------ > "Those who will not study history are doomed to debug it." > -- Barry Shein > ------------------------------------------------------------------------------ _______________________________________________ tboot-devel mailing list tboot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tboot-devel
