Hello Gang Wei,
thanks for your reply. Maybe I should just try and run tboot and see how it works before I write my own MLE :) You are right about the BIOS "moving" the 1 from bit 2 to bit 1 when I disable TXT. I just don't see the harm in having both bit 1 and bit 2 enabled when both TXT and VT is enabled. It's not like the hypervisor / guest will get access to "TXT secrets" in the TPM chip merely from being executed in this mode. Does DQ35MP/DQ35JO set the bits the same way? And do these motherboards provide a default SINIT at SINIT.BASE? I'm just asking out of curiosity since it is interesting to know how different vendors have gone about implementing TXT. The Asus mainboard is even a different BIOS brand than the Intel board. I guess we will see many more TXT-enabled mainboards once Intel moves the TPM into the chipsets later this year.
See my comments embeded.Jimmy
From: email@example.com [mailto:firstname.lastname@example.org] On Behalf Of Martin Thiim
Sent: Monday, February 18, 2008 1:55 AM
Subject: [tboot-devel] Question on feature control bits and some observationsHello,
I'm experimenting with Intel TXT. First I have one question. What exactly does the bit "Enable VMXON outside SMX operation" (bit 2 in IA32_FEATURE_CONTROL_MSR) do? On my mainboard (see below) this bit is set 0. >From the description in the documentation, I would assume this means that virtualization extensions can not be used without also using SMX, effectively implying that I won't be able to run, say, Xen (at least unless I apply a patch that enables SMX). Is this interpretation correct? If so, I don't really understand what purpose this bit serves, and why my mainboard apparently sets it to 0 (while allowing VMXON in SMX operation). Was this bit documented as part of the virtualization extensions all along, so that hypervisors that were written before the SMX documents became available, are aware that this bit needs to be 1?
[Jimmy] "Enable VMXON outside SMX operation" does mean enabling VMX operation without executing SMX instruction GETSEC[SENTER], just as your understanding. Usually the mainboard BIOS should have options to enable/disable TXT feature. If TXT is enabled, then BIOS usually clear the bit 2 of this MSR to forbiden usage of VMX before GETSEC[SENTER]; if TXT is disabled, BIOS will set this bit to allow usage of VMX without enter SMX environment. For hypervisors that were written before the SMX came into being and were using VMX , the TXT should be disabled via BIOS option, otherwise, "VMXON will cause a general-protection exception".
Now for the second point of my post, which is just for your information. As TXT hardware (to my knowledge) is only now becoming generally available, I figured my experience might be of interest. I originally bought a DQ35MP board, since it appeared to have everything necessary. Unfortunately, the particular board I got was defective and it would take a long time to get a new one from the supplier. So I swapped it for an Asus P5E-VM-DO board which also has the Q35 Express chipset, TPM onboard and features the vPro logo. I haven't started actually using TXT, so I can't say if it truly works with this board :) However, so far I have not encountered any "show stoppers" (such as necessary feature bits being disabled, CPU not detecting TXT-capable chipset etc.). These are my observations so far:
1) BIOS menu
The board has a BIOS menu option for enabling TXT. interestingly, it has sub-options for enabling/disabling SCHECK and SCLEAN. I haven't found much info on SCHECK and SCLEAN in Intel's documents, so I can't say what effect it would have to disable these modules. The menu points are grayed out, however, and are forced set to "Enabled" when TXT is enabled.
The lock bit (bit 0) is set by the BIOS. Bit 1 ("Enable VMXON in SMX operation") is set to 1 but bit 2 ("Enable VMXON outside SMX operation") is 0. All bits in the "SENTER enables" region are 1.
An Intel TXT-capable chipset is reported to be present (bit 0 set to 1). The following GETSEC leafs are reported to be available: ENTERACCS, EXITAC, SENTER, SEXIT, PARAMETERS, SMCTRL and WAKEUP (this is probably more CPU- than mainboard-specific).
4) Chipset registers:
LT.SINIT.BASE & LT.SINIT.SIZE appear to be set (the latter to 128K) but no SINIT module is located at the SINIT.BASE.
LT.HEAP.BASE is initialized and points to a valid TXT heap. BiosSinitSize is 0, correctly indicating that the BIOS doesn't provide a SINIT AC.
The LT.DIDVID register reports Vendor ID to be 0x8086 (Intel), DeviceID to be 0x8081 and RevisionID to be 0x0007. This matches the chipset ID in the BRLK_SINIT_20070910 available from the tboot sourceforge site.
[Jimmy] from your observations, it seems tboot can work on it to setup SMX environment and launch Xen hypervisor. Expecting your get back for the next experiment results. :)
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
tboot-devel mailing list