Hi all, Some observations and questions below. Answers would be great, but I also feel compelled to make some of this information available in case others find it useful. Happy reading!
I am writing in regard to some ambiguities in the MLE Developer's Guide and in Chapter 6 (Safer Mode Extensions Reference) of Volume 2B of the Intel Software Developer's Manual. I have been launching my MLE using the i5_i7_DUAL_SINIT_18.BIN. In particular, I am interested in a position-independent MLE that does not know its base address until runtime. I am trying to avoid "patching" the MLE any more than necessary prior to launch as this complicates verification of correct PCR values. The Intel MLE Developer's guide's Listing 7: MLE Initialization Pseudocode is written for an MLE that knows its runtime base address and immediately enables paging. Another important set of requirements are for a relocatable MLE that does not immediately enable paging. Chapter 6 of Volume 2B of the Intel Software Developer's Manual (Safer Mode Extensions Reference) describes the runtime environment for the MLE: "The SENTER leaf function also initializes some processor architecture state for the ILP from contents held in the header of the authenticated code module. Since the authenticated code module is relocatable, all address references are relative to the base address passed in via EBX. The ILP GDTR base value is initialized to EBX + [GDTBasePtr] and GDTR limit set to [GDTLimit]. The CS selector is initialized to the value held in the AC module header field SegSel, while the DS, SS, and ES selectors are initialized to CS+8. The segment descriptor fields are initialized implicitly with BASE=0, LIMIT=FFFFFh, G=1, D=1, P=1, S=1, read/write/accessed for DS, SS, and ES, while execute/read/accessed for CS. Execution in the authenticated code module for the ILP begins with the EIP set to EBX + [EntryPoint]. AC module defined fields used for initializing processor state are consistency checked with a failure resulting in an TXT-shutdown condition." This is somewhat troubling, as it sounds as though an MLE writer who wishes to write a position-independent MLE, especially one that does not immediately enable paging, is somewhat dependent on the "left-overs" of the SINIT module. There does not seem to be much of a "contract" regarding what the SINIT module must provide. Table 6-6 in Ch 6 Vol 2B comes close, stating that EBX should contain an unchanged SINIT.BASE, and that EBP should also contain SINIT.BASE. The above paragraph also suggests that CS, DS, and SS will all be flat 4GB segments. My observations contradict this. I have been unable to easily determine precisely what the base of the stack segment descriptor is, but it does not appear to be 0. I can push and pop values, but using the SS segment-override prefix has not allowed me to reference memory in a sane way. Dumping the GDT from within the SINIT binary file prior to launch, all entries do appear to be flat 4GB, so I am not sure why I observe strange behavior with SS. Does the SINIT module dynamically change the base for the stack segment descriptor at runtime? DS and CS do seem to be flat, and they work as expected. EBP does seem to contain SINIT.BASE, but EBX contains the MLE Entry Point on my system, not SINIT.BASE as suggested by Table 6-6. Is this an error in the Table? ECX appears to point to the base of the MLE page tables, which I believe is a feature supported by only *some* SINIT modules. To distill out some specific questions: 1. Is the entry in Table 6-6 for the value of EBX following SENTER incorrect? Should it instead read [EntryPoint from MLE Header]? 2. Will all future SINIT modules set ECX to be the MLE page table base address? I realize GETSEC[CAPABILITIES] may enable me to infer this prior to invoking SENTER, but if the check fails it's still somewhat unsatisfying. 3. What is going on with the stack segment descriptor following SENTER? I am afraid of clobbering unknown addresses by pushing and popping values before reloading a GDT, etc. ESP is initialized to 0x20000 (128K), which seems like a fairly reasonable default for an MLE. Or is this leftover from SINIT? Is SS set with the base address of the SINIT environment? I have *not* yet tried to store the GDTR prior to reloading it and lookup the active GDT upon entry into the MLE. This may be one route to provide an answer to question 3, however I'm hoping to avoid having to reverse-engineer it. Many thanks! -Jon ------------------------------------------------------------------------------ Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl _______________________________________________ tboot-devel mailing list tboot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tboot-devel
