As an update, I successfully rolled back my BIOS to an earlier version. With this change, tboot works again! GETSEC[SENTER] executes with no errors and I get into the secure state. So it is definitely some problem relating to the new BIOS.
Interestingly, I dumped the DMAR tables created by the working BIOS and they are byte for byte identical to what they were with the non-working BIOS. So clearly there is no point in going over those tables with a fine tooth comb to figure out what SINIT doesn't like about them. Something else must be different. I'd say the SINIT error codes are not particularly informative about what is going wrong in this case. I hope the SINIT team will still look into this. I can easily go back to the newer BIOS in order to reproduce the failing state. The new BIOS has the advantage that I can reboot after an SINIT failure and read the errorcode register. With the old BIOS, attempts to reboot hang in the BIOS and it's not possible to read the errorcodes, which made debugging TXT almost impossible. So I can either use the new BIOS which would allow some debugging but which unfortunately doesn't work with SINIT; or I can use the old BIOS which works with SINIT but reveals nothing when there is a failure. Neither is a great alternative. Hal Finney ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ tboot-devel mailing list tboot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tboot-devel
