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

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

DQ35MP/DQ35JO should set the bits the same way. Motherboards can provide
a default SINIT at SINIT.BASE, but I presume current boards don't
provide it. I am also looking forward to see more TXT-enabled boards.

Jimmy

________________________________

From: tbo...@li...
[mailto:tbo...@li...] On Behalf Of Martin
Thiim
Sent: Tuesday, February 19, 2008 10:48 PM
To: tbo...@li...
Subject: Re: [tboot-devel] Question on feature control bits and
someobservations

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