I already removed the vga argument. We may need a BIOS update, looking into that as well at the moment.
On 09/02/2016 01:24 PM, Ahmed, Safayet (GE Global Research, US) wrote: > 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
