>From the TXT Software Developer's guide (Appendix I), it says that the error >is valid, from external software (like the ACM), from the SINIT ACM (and not >the BIOS ACM), and class C, major (8), minor (0) . Without the PDF that comes >with the SINIT ACM it's difficult to decipher that any further.
Just as a shot in the dark, just based on past experience, you could try removing the "vga" argument from the TBoot boot arguments related to logging. I don't know if that will work (it has for me in the past) and don't ask me to explain why. Safayet -----Original Message----- From: Brian E Luckau [mailto:bluc...@sgi.com] Sent: Friday, September 02, 2016 2:50 PM To: Sun, Ning <ning....@intel.com>; g...@enjellic.com; 'tboot-devel@lists.sourceforge.net' <tboot-devel@lists.sourceforge.net> Subject: EXT: Re: [tboot-devel] reset after GETSEC[SENTER] on redhat platforms 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://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_01org_ > TPM2.0-2DTSS&d=CwICAg&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r= > lDSLRzn8YUPmwjLuy9Ek9Dy-T15T3uK505eKqf1EFfg&m=6DCAR_wy-l6xLi7hLA6rjaTi > mncsWWNOlrw-ft41Fec&s=R210LrvRKPPbIxG_HrcHZ2NuHxSnma3VfuPdPXTGCHM&e= > *TSS2 based tpm2-tools: > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_01org_ > tpm2.0-2Dtools&d=CwICAg&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI& > r=lDSLRzn8YUPmwjLuy9Ek9Dy-T15T3uK505eKqf1EFfg&m=6DCAR_wy-l6xLi7hLA6rja > TimncsWWNOlrw-ft41Fec&s=kxQxUE0rMX4knGvrP92YuZFvgBXH3bDZ-kHvCVEfjUs&e= > *IBM: > https://urldefense.proofpoint.com/v2/url?u=http-3A__sourceforge.net_pr > ojects_ibmtpm20tss_&d=CwICAg&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQ > YWSI&r=lDSLRzn8YUPmwjLuy9Ek9Dy-T15T3uK505eKqf1EFfg&m=6DCAR_wy-l6xLi7hL > A6rjaTimncsWWNOlrw-ft41Fec&s=Um7J7QmyIqlkpus7c170KU2H-R7fdIcbLMNBUhsPk > tU&e= > > > 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://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_tboot-2Ddevel&d=CwICAg&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=lDSLRzn8YUPmwjLuy9Ek9Dy-T15T3uK505eKqf1EFfg&m=6DCAR_wy-l6xLi7hLA6rjaTimncsWWNOlrw-ft41Fec&s=4giLByj9PfSfZN-z_SkB4xkuZda3VrXDv9cd08mmtWo&e= ------------------------------------------------------------------------------ _______________________________________________ tboot-devel mailing list tboot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tboot-devel
