Re: [tboot-devel] Question on feature control bits and some observations

[Martin T. <ma...@th...>]

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.

Best regards,

Martin Thiim


On 2/19/08, Wei, Gang <gan...@in...> wrote:
>
>  See my comments embeded.
>
> Jimmy
>
>  ------------------------------
> *From:* tbo...@li... [mailto:
> tbo...@li...] *On Behalf Of *Martin Thiim
> *Sent:* Monday, February 18, 2008 1:55 AM
> *To:* tbo...@li...
> *Subject:* [tboot-devel] Question on feature control bits and some
> observations
>
>  Hello,
>
> 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.
>
> 2) IA32_FEATURE_CONTROL_MSR:
> 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.
>
> 3) GETSEC[CAPABILITIES]:
> 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. :)
>
> Best regards,
>
> Martin Thiim
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> tboot-devel mailing list
> tbo...@li...
> https://lists.sourceforge.net/lists/listinfo/tboot-devel
>
>