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

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Let me try to address the various questions below:

On Tuesday, February 19, 2008 7:05 AM, Wei, Gang wrote:
> 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

It would provide a good baseline to verify that a known-working MLE
fucntions properly on your system before making changes.

> "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

The intention of disabling VMX outside of SMX when TXT has been enabled
is that by enabling TXT the user is signalling that they wish to use the
platform in a secure mode.  And by disabling VMX outside of SMX, then
once a launch control policy has been established, the system is
protected from a blue-pill type of attack (or if a launch control policy
is not present then at least blue-pill must perform a measured launch
and will be detectable in the PCR state).

> 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.

These are functions of the BIOS AC Module that are not intended for user
control (hence the greying out).

> 
> 	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
> 
> 
> 
> 
> 
>
------------------------------------------------------------------------
-
> 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