*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 index 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 ------------------------------------------------------------------------------ _______________________________________________ tboot-devel mailing list tboot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tboot-devel