tboot-devel — Developer support

Re: [tboot-devel] How to validate the PCR measured by TXT?

[Hal F. <hal...@gm...>]

On Thu, Apr 17, 2008 at 4:31 AM, Seiji Munetoh <sei...@gm...> wrote:
> Hi Folks,
>
>  Is there any way to validate the PCR[17] and PCR18] values?
>
>  In case of Static-RTM, we can validate the PCR values by using
>  the BIOS eventlog stored at ACPI table.
>  But for Dynamic-RTM we don't have such eventlog.
>
>  I just tried different tpm_extend combinations from digests
>  in the tboot's console message. but I can't find the right
>  combination to produce the PCR17,18 values.

Hi, Seiji - Joseph Cihula shared the information below with me that
explains what goes into PCR 17 and PCR 18. He says it will go into the
next edition of the TXT architecture spec:

:: >>> I wonder if you could report what is in PCR17 after a tboot launch
:: >>> using this SINIT module?
:: >>
:: >> I'm planning to update the TXT Prelim Arch Spec with this
:: information,
:: >> but in the meantime, the contents are:
:: >>     TPM_Extend( SHA1( SINIT AC module) )
:: >>     TPM_Extend( SHA1( SCLEAN hash (20 bytes) | MsrValidBit (8 bytes) |
:: >> StmDigest (20 bytes) | LCP Control Field (4 bytes) | LCP Hash
(20 bytes) ) )
:: >> where the second extend is the hash of the concatenation of the
:: >> specified values (72 bytes in all).  You can get the listed values from
:: >> the SinitMleData structure.
:: >
:: > In looking at the SinitMleData structure in section C.4 of the
:: > document, some of these fields have slightly different names. No
:: > SCLEAN hash is listed, rather there is an SinitHash at offset 36. Is
:: > this actually an SCLEAN AC module hash? Then, MsrValidBit is called
:: > MsegValid and relates to the SMM Transfer Module stuff that I don't
:: > understand yet. StmDigest is StmHash, LCP Control Field is
:: > PolicyControl, and LCP Hash is LcpPolicyHash. So the main question
:: > here is the SINIT vs SCLEAN hash.
::
:: Sorry for the confusion--here is the mapping of terms above to fields in
:: SinitMleData:
::
:: SCLEAN hash -> BiosAcmID
:: MsrValidBit -> MsegValid
:: StmDigest -> StmHash
:: LCP Control Field -> PolicyControl
:: LCP Hash -> LcpPolicyHash
::
:: >>> And then (sorry about so many questions!) how about the measurement of
:: >>> the MLE, which gets hashed, I think, into PCR18 (or maybe PCR19)? Is
:: >>> there any information about that, what exactly is hashed and what
:: >>> sequence of extends are done?
:: >>
:: >> The hash of the MLE is extended into PCR 18.
:: >
:: > I see, thanks. I'm a little unclear about what exactly is hashed
:: > though. It looks like it might be the linear-address region (under the
:: > mapping defined by the MLE page tables) starting from the
:: > FirstValidPage field in the MLE header as described in Table 9, and
:: > extending for "MLE size" bytes as recorded in the OsSinitData
:: > structure? Does that sound right?
::
:: PCR 18 is extended with the hash of the MLE, as described by the MLE
:: page table.  The hashing starts at the first valid page and continues
:: until a non-valid page.  It will hash to the size specified by
:: OsSinitData.MleSize.

Seiji, have you tried reading PCR 17 and PCR 18? What values do you get?


>  I'm using Fedora8 and Xen-3.2 on DQ35JO board (BIOS v865)
>  and my grub.conf is
>
>  title Fedora (2.6.21.7-2.fc8xen) XEN 3.2 w/ TBOOT
>         root (hd0,4)
>         kernel /boot/tboot.gz
>         module /boot/xen.gz-3.2 vtd=1 com1=115200,8n1
>         module /boot/vmlinuz-2.6.21.7-2.fc8xen ro root=LABEL=/1
>         module /boot/initrd-2.6.21.7-2.fc8xen.img
>         module /boot/BRLK_SINIT_20070910_release.BIN
>
>  Actually, the xen and kernel digest I found in the console massage
>  were correct (same as the sha1 digest of  gunziped file).
>
>  But, the digest of SINIT code was somehow different.
>
>  TBOOT:   sinit_hash=
>         b2 12 60 68 7f 26 f0 cd a9 c7 5e 81 ff 78 92 72 1d 50 ed 4d
>
>  # sha1sum /boot/BRLK_SINIT_20070910_release.BIN
>  46f4e1c199c2983e8a8a115cd90c88353e7b08dc

The sinit_hash is not the hash of the entire SINIT module, but only of
certain portions of it. This is described in section A.1.2 of the
Preliminary Architecture Specification: "The RSA Signature signs an
area that includes the sum of the module header and all of the USER
AREA data field,
which represents the body of the module. Those parts of the module header not
included are: the RSA Signature, the public key, and the scratch
field." This is the data which gets hashed to form sinit_hash.

Hal Finney

[tboot-devel] How to validate the PCR measured by TXT?

[Seiji M. <sei...@gm...>]

Hi Folks,

Is there any way to validate the PCR[17] and PCR18] values?

In case of Static-RTM, we can validate the PCR values by using
the BIOS eventlog stored at ACPI table.
But for Dynamic-RTM we don't have such eventlog.

I just tried different tpm_extend combinations from digests
in the tboot's console message. but I can't find the right
combination to produce the PCR17,18 values.

I'm using Fedora8 and Xen-3.2 on DQ35JO board (BIOS v865)
and my grub.conf is

title Fedora (2.6.21.7-2.fc8xen) XEN 3.2 w/ TBOOT
        root (hd0,4)
        kernel /boot/tboot.gz
        module /boot/xen.gz-3.2 vtd=1 com1=115200,8n1
        module /boot/vmlinuz-2.6.21.7-2.fc8xen ro root=LABEL=/1
        module /boot/initrd-2.6.21.7-2.fc8xen.img
        module /boot/BRLK_SINIT_20070910_release.BIN

Actually, the xen and kernel digest I found in the console massage
were correct (same as the sha1 digest of  gunziped file).

But, the digest of SINIT code was somehow different.

TBOOT:   sinit_hash=
        b2 12 60 68 7f 26 f0 cd a9 c7 5e 81 ff 78 92 72 1d 50 ed 4d

# sha1sum /boot/BRLK_SINIT_20070910_release.BIN
46f4e1c199c2983e8a8a115cd90c88353e7b08dc

Thanks,
--
Seiji

Re: [tboot-devel] recommended system?

[Seiji M. <sei...@gm...>]

Hi,

2008/4/10, Cihula, Joseph <jos...@in...>:
>  The Intel DQ35JO motherboard, with the latest BIOS (v757), still has a
>  few TXT issues.  The fixes are currently under test.

I have tested the tboot on DQ35JO with new BIOS (v865).
and it launches correctly.

Thanks,
--
Seiji

Re: [tboot-devel] recommended system?

[Cihula, J. <jos...@in...>]

On Friday, April 04, 2008 8:16 AM, Jason Kynes wrote:
> I've seen several reports on systems that don't seem to work with
> tboot (e.g. Dell Optiplex 755) and only one report of success (HP
> dc7800) that wasn't repeatable onto an almost identical machine. Is
> there a commercially available system that's known to work
> consistently with tboot or is it basically limited to SDPs at this
> point?
> 
> Thanks,
> Jason

Jason,

I have verified that the current tboot code (the tip of the mercurial
tree) launches correctly on an HP dc7800 (I don't remember the BIOS
version).  I do not know if launch failures will cause a hang on reboot
with their latest BIOS or not.  HP is aware of the issue with hanging on
reboots and is working on a fix if they do not already have it
available.  The issue, though, is only seen when the launch fails.

I have been told that the Dell Optiplex 755 with the most recent BIOS
also performs a TXT launch correctly and that it does not have an issue
with hanging on failures.

The Intel DQ35JO motherboard, with the latest BIOS (v757), still has a
few TXT issues.  The fixes are currently under test.

The tip of the current tboot code has several fixes related to TPM
timeouts and proper state handling.  These (now fixed) TPM issues were
responsible for some of the reported failures.

Joe

[tboot-devel] recommended system?

[Jason K. <jas...@gm...>]

I've seen several reports on systems that don't seem to work with
tboot (e.g. Dell Optiplex 755) and only one report of success (HP
dc7800) that wasn't repeatable onto an almost identical machine. Is
there a commercially available system that's known to work
consistently with tboot or is it basically limited to SDPs at this
point?

Thanks,
Jason

Re: [tboot-devel] Fwd: User guide for applying the TXT patch

[Cihula, J. <jos...@in...>]

What system are you trying to run this on?  If it is a laptop, I don't
believe that there are any notebooks that support TXT currently.
 
If your serial port and terminal program (you can use hyperterm on
Windows or minicom on Linux) are workign correctly, the serial and
terminal directives to GRUB should cause you to get the GRUB boot menu
on the terminal.
 
Also, is your sinit.bin just BRLK_SINIT_20070910_release.BIN renamed?
 
Joe


________________________________

	From: tbo...@li...
[mailto:tbo...@li...] On Behalf Of Tresko
	Sent: Friday, March 28, 2008 11:02 AM
	To: tbo...@li...
	Subject: Re: [tboot-devel] Fwd: User guide for applying the TXT
patch
	
	


	Hi Joe
	
	I did connect the serial port on my notebook to a monitor and
reboot the system, but the monitor doesn't display anything. Is there
any way where I can get the serial output? I am not sure if this helps
but, in the grub (with 'kernel /tboot.gz' included) when I remove the
'module /sinit.bin' ( this file is for the x86_64 arch). I can boot into
the second boot option. Thanks
	
	
	Tresko 


	On Fri, Mar 28, 2008 at 10:31 AM, Cihula, Joseph
<jos...@in...> wrote:
	

		Please send the serial output of the failed boot, and if
it causes a reset, of the next failed boot after that.
		 
		Joe

Re: [tboot-devel] Fwd: User guide for applying the TXT patch

[Tresko <tr...@gm...>]

Hi Joe

I did connect the serial port on my notebook to a monitor and reboot the
system, but the monitor doesn't display anything. Is there any way where I
can get the serial output? I am not sure if this helps but, in the grub
(with 'kernel /tboot.gz' included) when I remove the 'module /sinit.bin' (
this file is for the x86_64 arch). I can boot into the second boot option.
Thanks


Tresko


On Fri, Mar 28, 2008 at 10:31 AM, Cihula, Joseph <jos...@in...>
wrote:

>  Please send the serial output of the failed boot, and if it causes a
> reset, of the next failed boot after that.
>
> Joe
>

Re: [tboot-devel] Fwd: User guide for applying the TXT patch

[Cihula, J. <jos...@in...>]

Please send the serial output of the failed boot, and if it causes a
reset, of the next failed boot after that.
 
Joe


________________________________

	From: tbo...@li...
[mailto:tbo...@li...] On Behalf Of Tresko
	Sent: Friday, March 28, 2008 7:59 AM
	To: tbo...@li...
	Subject: Re: [tboot-devel] Fwd: User guide for applying the TXT
patch
	
	
	Hi Joe
	
	Thank you for the reply. I am sorry actually I forgot to include
some more details here. After I ran the "make intall" it did create
tboot.gz in the boot directory and I did make the change in the grub as
follows :
	
	
	# grub.conf generated by anaconda
	#
	# Note that you do not have to rerun grub after making changes
to this file
	# NOTICE:  You have a /boot partition.  This means that
	#          all kernel and initrd paths are relative to /boot/,
eg.
	#          root (hd0,0)
	#          kernel /vmlinuz-version ro root=/dev/sda2
	#          initrd /initrd-version.img
	#boot=/dev/sda
	default=0
	timeout=5
	splashimage=(hd0,0)/grub 
	/splash.xpm.gz
	hiddenmenu

	serial --unit=0 --speed=115200 --parity=no --stop=1
	terminal --timeout=10 serial console
	
	
	title Fedora (2.6.21-1.3194.fc7)
	    root (hd0,0)
	    kernel /vmlinuz-2.6.21-1.3194.fc7 ro root=LABEL=/ rhgb quiet
	    initrd /initrd-2.6.21-1.3194.fc7.img


	title Fedora Core (Xen 3.2.0 with TXT)
	root (hd0,0)
	kernel /tboot.gz
	module /xen.gz com1=115200,8n1 vtd=1 console=com1
	module /vmlinuz-2.6.18.8-xen root=LABEL=/ ro console=tty0
	console=ttyS0,115200,8n1 pciback.hide=(01:00.0)
	pciback.verbose_request=1 acpi=debug pci=nommconf
	module /initrd-2.6.18.8-xen.img
	module /sinit.bin


	This is when the computer was not able to boot into the 'Fedora
Core (Xen 3.2.0 with TXT)' and so I had to remove the tboot line in the
grub. So this once again leaves me with the original problem I mentioned
before. Thanks
	
	Karthik
	
	
	---------- Forwarded message ----------
	From: Cihula, Joseph <jos...@in...>
	Date: Fri, Mar 28, 2008 at 12:06 AM
	Subject: RE: [tboot-devel] Fwd: User guide for applying the TXT
patch
	To: Tresko <tr...@gm...>,
tbo...@li...
	
	
	
	Tresko,
	 
	See '[JC]' below:
	 
	Joe
	P.S.  The tboot-devel list is moderated, so if you don't join it
then all of your emails need to be specifically approved.  Not a
problem, but just FYI.


________________________________

		From: tbo...@li...
[mailto:tbo...@li...] On Behalf Of Tresko
		Sent: Thursday, March 27, 2008 1:59 PM 

		To: tbo...@li...
		
		Subject: [tboot-devel] Fwd: User guide for applying the
TXT patch
		
		
		
		
		
		---------- Forwarded message ----------
		From: Tresko <tr...@gm...>
		Date: Thu, Mar 27, 2008 at 3:49 PM
		Subject: Re: [tboot-devel] User guide for applying the
TXT patch
		To: tbo...@li...
		
		
		Hi Joe
		
		I have one more question. Simply installing Xen doesn't
create any tboot.gz so I had to download the tboot-20071128.tar.gz
<http://downloads.sourceforge.net/tboot/tboot-20071128.tar.gz?modtime=11
96353121&big_mirror=0>  and unzip it and run 'make -j8 world' ..it gives
me error.I ignored and went ahead and did 'make install'  and modified
the grub. Here is my grub output: 
		[JC]  There is a target called 'install-tboot' in the
makefile that will download, build, and install tboot.  It is not
invoked as part of any of the Xen targets, so you have to do it
manually.  


		# grub.conf generated by anaconda
		#
		# Note that you do not have to rerun grub after making
changes to this file
		# NOTICE:  You have a /boot partition.  This means that
		#          all kernel and initrd paths are relative to
/boot/, eg.
		#          root (hd0,0)
		#          kernel /vmlinuz-version ro root=/dev/sda2
		#          initrd /initrd-version.img
		#boot=/dev/sda
		default=0
		timeout=5
		splashimage=(hd0,0)/grub
		/splash.xpm.gz
		hiddenmenu
		
		serial --unit=0 --speed=115200 --parity=no --stop=1
		terminal --timeout=10 serial console
		
		
		title Fedora (2.6.21-1.3194.fc7)
		    root (hd0,0)
		    kernel /vmlinuz-2.6.21-1.3194.fc7 ro root=LABEL=/
rhgb quiet
		    initrd /initrd-2.6.21-1.3194.fc7.img
		
		
		title Fedora Core (Xen 3.2.0 with TXT)
		root (hd0,0)
		kernel /xen.gz com1=115200,8n1 vtd=1 console=com1
		module /vmlinuz-2.6.18.8-xen root=LABEL=/ ro
console=tty0
		console=ttyS0,115200,8n1 pciback.hide=(01:00.0)
		pciback.verbose_request=1 acpi=debug pci=nommconf
		module /initrd-2.6.18.8-xen.img
		
		module /sinit.bin
		
		
		After this is tried to boot into the 'Fedora Core (Xen
3.2.0 with TXT)' option but the system can't boot into this.Can you
please tell me if I am missing anything here? I would really appreciate
it if you can provide some light into this issue. Also I am new to
vitualization and TXT. Thanks 
		[JC]  From the README in tboot, here is an example
grub.conf for tboot:
		       title Xen 3.1.0 w/ Intel(R) Trusted Execution
Technology
		           root (hd0,1)
		           kernel /tboot.gz
		           module /xen.gz vtd=1 dom0_mem=524288
com1=115200,8n1
		           module /vmlinuz-2.6.18-xen
root=/dev/VolGroup00/LogVol00 ro
		           module /initrd-2.6.18-xen.img
		           module /BRLK_SINIT_20070910_release.BIN
		Yours is missing tboot.gz as the kernel.
		 
		
		Tresko

Re: [tboot-devel] Fwd: User guide for applying the TXT patch

[Tresko <tr...@gm...>]

Hi Joe

Thank you for the reply. I am sorry actually I forgot to include some more
details here. After I ran the "make intall" it did create tboot.gz in the
boot directory and I did make the change in the grub as follows :


# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making changes to this file
# NOTICE:  You have a /boot partition.  This means that
#          all kernel and initrd paths are relative to /boot/, eg.
#          root (hd0,0)
#          kernel /vmlinuz-version ro root=/dev/sda2
#          initrd /initrd-version.img
#boot=/dev/sda
default=0
timeout=5
splashimage=(hd0,0)/grub /splash.xpm.gz
hiddenmenu

serial --unit=0 --speed=115200 --parity=no --stop=1
terminal --timeout=10 serial console

title Fedora (2.6.21-1.3194.fc7)
    root (hd0,0)
    kernel /vmlinuz-2.6.21-1.3194.fc7 ro root=LABEL=/ rhgb quiet
    initrd /initrd-2.6.21-1.3194.fc7.img


title Fedora Core (Xen 3.2.0 with TXT)
root (hd0,0)
kernel /tboot.gz
module /xen.gz com1=115200,8n1 vtd=1 console=com1
module /vmlinuz-2.6.18.8-xen root=LABEL=/ ro console=tty0
console=ttyS0,115200,8n1 pciback.hide=(01:00.0)
pciback.verbose_request=1 acpi=debug pci=nommconf
module /initrd-2.6.18.8-xen.img
module /sinit.bin


This is when the computer was not able to boot into the 'Fedora Core (Xen
3.2.0 with TXT)' and so I had to remove the tboot line in the grub. So this
once again leaves me with the original problem I mentioned before. Thanks

Karthik

---------- Forwarded message ----------
From: Cihula, Joseph <jos...@in...>
Date: Fri, Mar 28, 2008 at 12:06 AM
Subject: RE: [tboot-devel] Fwd: User guide for applying the TXT patch
To: Tresko <tr...@gm...>, tbo...@li...


 Tresko,

See '[JC]' below:

Joe
P.S.  The tboot-devel list is moderated, so if you don't join it then all of
your emails need to be specifically approved.  Not a problem, but just FYI.

 ------------------------------
*From:* tbo...@li... [mailto:
tbo...@li...] *On Behalf Of *Tresko
*Sent:* Thursday, March 27, 2008 1:59 PM
*To:* tbo...@li...
*Subject:* [tboot-devel] Fwd: User guide for applying the TXT patch



---------- Forwarded message ----------
From: Tresko <tr...@gm...>
Date: Thu, Mar 27, 2008 at 3:49 PM
Subject: Re: [tboot-devel] User guide for applying the TXT patch
To: tbo...@li...


Hi Joe

I have one more question. Simply installing Xen doesn't create any
tboot.gzso I had to download the
tboot-20071128.tar.gz<http://downloads.sourceforge.net/tboot/tboot-20071128.tar.gz?modtime=1196353121&big_mirror=0>and
unzip it and run 'make -j8 world' ..it gives me
error.I ignored and went ahead and did 'make install'  and modified the
grub. Here is my grub output:
[JC]  There is a target called 'install-tboot' in the makefile that will
download, build, and install tboot.  It is not invoked as part of any of the
Xen targets, so you have to do it manually.


# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making changes to this file
# NOTICE:  You have a /boot partition.  This means that
#          all kernel and initrd paths are relative to /boot/, eg.
#          root (hd0,0)
#          kernel /vmlinuz-version ro root=/dev/sda2
#          initrd /initrd-version.img
#boot=/dev/sda
default=0
timeout=5
splashimage=(hd0,0)/grub
/splash.xpm.gz
hiddenmenu

serial --unit=0 --speed=115200 --parity=no --stop=1
terminal --timeout=10 serial console

title Fedora (2.6.21-1.3194.fc7)
    root (hd0,0)
    kernel /vmlinuz-2.6.21-1.3194.fc7 ro root=LABEL=/ rhgb quiet
    initrd /initrd-2.6.21-1.3194.fc7.img


title Fedora Core (Xen 3.2.0 with TXT)
root (hd0,0)
kernel /xen.gz com1=115200,8n1 vtd=1 console=com1
module /vmlinuz-2.6.18.8-xen root=LABEL=/ ro console=tty0
console=ttyS0,115200,8n1 pciback.hide=(01:00.0)
pciback.verbose_request=1 acpi=debug pci=nommconf
module /initrd-2.6.18.8-xen.img
module /sinit.bin


After this is tried to boot into the 'Fedora Core (Xen 3.2.0 with TXT)'
option but the system can't boot into this.Can you please tell me if I am
missing anything here? I would really appreciate it if you can provide some
light into this issue. Also I am new to vitualization and TXT. Thanks
[JC]  From the README in tboot, here is an example grub.conf for tboot:
       title Xen 3.1.0 w/ Intel(R) Trusted Execution Technology
           root (hd0,1)
           kernel /tboot.gz
           module /xen.gz vtd=1 dom0_mem=524288 com1=115200,8n1
           module /vmlinuz-2.6.18-xen root=/dev/VolGroup00/LogVol00 ro
           module /initrd-2.6.18-xen.img
           module /BRLK_SINIT_20070910_release.BIN
Yours is missing tboot.gz as the kernel.


Tresko

Re: [tboot-devel] Fwd: User guide for applying the TXT patch

[Cihula, J. <jos...@in...>]

Tresko,
 
See '[JC]' below:
 
Joe
P.S.  The tboot-devel list is moderated, so if you don't join it then
all of your emails need to be specifically approved.  Not a problem, but
just FYI.


________________________________

	From: tbo...@li...
[mailto:tbo...@li...] On Behalf Of Tresko
	Sent: Thursday, March 27, 2008 1:59 PM
	To: tbo...@li...
	Subject: [tboot-devel] Fwd: User guide for applying the TXT
patch
	
	
	
	
	
	---------- Forwarded message ----------
	From: Tresko <tr...@gm...>
	Date: Thu, Mar 27, 2008 at 3:49 PM
	Subject: Re: [tboot-devel] User guide for applying the TXT patch
	To: tbo...@li...
	
	
	Hi Joe
	
	I have one more question. Simply installing Xen doesn't create
any tboot.gz so I had to download the tboot-20071128.tar.gz
<http://downloads.sourceforge.net/tboot/tboot-20071128.tar.gz?modtime=11
96353121&big_mirror=0>  and unzip it and run 'make -j8 world' ..it gives
me error.I ignored and went ahead and did 'make install'  and modified
the grub. Here is my grub output: 
	[JC]  There is a target called 'install-tboot' in the makefile
that will download, build, and install tboot.  It is not invoked as part
of any of the Xen targets, so you have to do it manually. 
	
	# grub.conf generated by anaconda
	#
	# Note that you do not have to rerun grub after making changes
to this file
	# NOTICE:  You have a /boot partition.  This means that
	#          all kernel and initrd paths are relative to /boot/,
eg.
	#          root (hd0,0)
	#          kernel /vmlinuz-version ro root=/dev/sda2
	#          initrd /initrd-version.img
	#boot=/dev/sda
	default=0
	timeout=5
	splashimage=(hd0,0)/grub
	/splash.xpm.gz
	hiddenmenu
	
	serial --unit=0 --speed=115200 --parity=no --stop=1
	terminal --timeout=10 serial console
	
	
	title Fedora (2.6.21-1.3194.fc7)
	    root (hd0,0)
	    kernel /vmlinuz-2.6.21-1.3194.fc7 ro root=LABEL=/ rhgb quiet
	    initrd /initrd-2.6.21-1.3194.fc7.img
	
	
	title Fedora Core (Xen 3.2.0 with TXT)
	root (hd0,0)
	kernel /xen.gz com1=115200,8n1 vtd=1 console=com1
	module /vmlinuz-2.6.18.8-xen root=LABEL=/ ro console=tty0
	console=ttyS0,115200,8n1 pciback.hide=(01:00.0)
	pciback.verbose_request=1 acpi=debug pci=nommconf
	module /initrd-2.6.18.8-xen.img
	
	module /sinit.bin
	
	
	After this is tried to boot into the 'Fedora Core (Xen 3.2.0
with TXT)' option but the system can't boot into this.Can you please
tell me if I am missing anything here? I would really appreciate it if
you can provide some light into this issue. Also I am new to
vitualization and TXT. Thanks 
	[JC]  From the README in tboot, here is an example grub.conf for
tboot:
	       title Xen 3.1.0 w/ Intel(R) Trusted Execution Technology
	           root (hd0,1)
	           kernel /tboot.gz
	           module /xen.gz vtd=1 dom0_mem=524288 com1=115200,8n1
	           module /vmlinuz-2.6.18-xen
root=/dev/VolGroup00/LogVol00 ro
	           module /initrd-2.6.18-xen.img
	           module /BRLK_SINIT_20070910_release.BIN
	Yours is missing tboot.gz as the kernel.
	 
	
	Tresko

[tboot-devel] Fwd: User guide for applying the TXT patch

[Tresko <tr...@gm...>]

---------- Forwarded message ----------
From: Tresko <tr...@gm...>
Date: Thu, Mar 27, 2008 at 3:49 PM
Subject: Re: [tboot-devel] User guide for applying the TXT patch
To: tbo...@li...


Hi Joe

I have one more question. Simply installing Xen doesn't create any
tboot.gzso I had to download the
tboot-20071128.tar.gz<http://downloads.sourceforge.net/tboot/tboot-20071128.tar.gz?modtime=1196353121&big_mirror=0>and
unzip it and run 'make -j8 world' ..it gives me
error.I ignored and went ahead and did 'make install'  and modified the
grub. Here is my grub output:

# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making changes to this file
# NOTICE:  You have a /boot partition.  This means that
#          all kernel and initrd paths are relative to /boot/, eg.
#          root (hd0,0)
#          kernel /vmlinuz-version ro root=/dev/sda2
#          initrd /initrd-version.img
#boot=/dev/sda
default=0
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
serial --unit=0 --speed=115200 --parity=no --stop=1
terminal --timeout=10 serial console

title Fedora (2.6.21-1.3194.fc7)
    root (hd0,0)
    kernel /vmlinuz-2.6.21-1.3194.fc7 ro root=LABEL=/ rhgb quiet
    initrd /initrd-2.6.21-1.3194.fc7.img

title Fedora Core (Xen 3.2.0 with TXT)
root (hd0,0)
kernel /xen.gz com1=115200,8n1 vtd=1 console=com1
module /vmlinuz-2.6.18.8-xen root=LABEL=/ ro console=tty0
console=ttyS0,115200,8n1 pciback.hide=(01:00.0)
pciback.verbose_request=1 acpi=debug pci=nommconf
module /initrd-2.6.18.8-xen.img
module /sinit.bin


After this is tried to boot into the 'Fedora Core (Xen 3.2.0 with TXT)'
option but the system can't boot into this.Can you please tell me if I am
missing anything here? I would really appreciate it if you can provide some
light into this issue. Also I am new to vitualization and TXT. Thanks

Tresko

Re: [tboot-devel] User guide for applying the TXT patch

[Cihula, J. <jos...@in...>]

The README file in Xen 3.2 (and -unstable) has instructions near the end
for how to integrate tboot with Xen (which really just consists of the
appropriate changes to grub.conf).  As of Xen 3.2, no patches are
required to Xen itself to enable TXT/tboot (i.e. the necessary code is
already in the Xen source tree).
 
Joe


________________________________

	From: tbo...@li...
[mailto:tbo...@li...] On Behalf Of Tresko
	Sent: Wednesday, March 12, 2008 9:51 AM
	To: tbo...@li...
	Subject: [tboot-devel] User guide for applying the TXT patch
	
	

	Hi 
	
	I have gone through different mailing list but none of them
explicitly talked about the steps to follow to apply this TXT patch. I
would appreciate it if you can post a user manual that helps us
understand how to install a xen with txt support. Thanks in advance
	
	Tresko
	

[tboot-devel] User guide for applying the TXT patch

[Tresko <tr...@gm...>]

Hi

I have gone through different mailing list but none of them explicitly
talked about the steps to follow to apply this TXT patch. I would appreciate
it if you can post a user manual that helps us understand how to install a
xen with txt support. Thanks in advance

Tresko

Re: [tboot-devel] [Q] HITM on Intel TXT manual

[Atsushi S. <sa...@jp...>]

Thank you
It seems common words.
http://www.intel.com/design/Itanium2/manuals/25110901.pdf

Thanks
Atsushi SAKAI


"Wang, Shane" <sha...@in...> wrote:

> I think it is Hit Modified, which indicates a caching agent holds a
> modified version of the requested line and this agent assumes
> responsibility for providing the line.
> 
> This is in "Intel 850 Chipset Family MCH Datasheet".
> 
> Shane
> 
> Atsushi SAKAI wrote:
> > Hi,
> > 
> > I have a question about TXT preliminary Specification.
> > I would be appreciated if you  explain the word "HITM" mean?
> > http://download.intel.com/technology/security/downloads/31516804.pdf
> > 
> > Thanks
> > Atsushi SAKAI
> > 
> > 
> > 
> > 
> > 
> >
> ------------------------------------------------------------------------
> -
> > 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
> 

Re: [tboot-devel] [Q] HITM on Intel TXT manual

[Wang, S. <sha...@in...>]

I think it is Hit Modified, which indicates a caching agent holds a
modified version of the requested line and this agent assumes
responsibility for providing the line.

This is in "Intel 850 Chipset Family MCH Datasheet".

Shane

Atsushi SAKAI wrote:
> Hi,
> 
> I have a question about TXT preliminary Specification.
> I would be appreciated if you  explain the word "HITM" mean?
> http://download.intel.com/technology/security/downloads/31516804.pdf
> 
> Thanks
> Atsushi SAKAI
> 
> 
> 
> 
> 
>
------------------------------------------------------------------------
-
> 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

[tboot-devel] [Q] HITM on Intel TXT manual

[Atsushi S. <sa...@jp...>]

Hi,

I have a question about TXT preliminary Specification.
I would be appreciated if you  explain the word "HITM" mean?
http://download.intel.com/technology/security/downloads/31516804.pdf

Thanks
Atsushi SAKAI

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

[Cihula, J. <jos...@in...>]

Below:


________________________________

	From: Martin Thiim [mailto:ma...@th...] 
	Sent: Wednesday, February 20, 2008 12:08 AM
	To: Cihula, Joseph
	Cc: Wei, Gang; tbo...@li...
	Subject: Re: [tboot-devel] Question on feature control bits
andsomeobservations
	
	
	Hello,
	 
	thanks for your reply, my comments below:
	
	> 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).
	 
	I don't see how disabling VMX outside SMX adds any security,
since full virtualization is still possible in software, it just can't
take advantage of VMX. VMWare and others have offered "near native"
virtualization performance even before VMX. So it would still be
possible to do a full (in software) virtualization of the CPU, including
SMX features, opening up for a "blue-pill" attack.  
	 
	
	[JC]  While there is certainly SW-based virtualization, it is
much harder for SW virt. to be completely transparent and undetectable.
And while I can't say for sure that HW-based virt. is undetectable,
there are those that make the claim that it can be (and those that claim
it can't).  SW-based virt. is also more complex than HW-based virt.  So
preventing the use of HW-based virt. does provide some level of
protection from hyperjacking. 
	 
	 Of course, it wouldn't be possible to "fake" the PCR registers
on the true TPM so it wouldn't be able to extract any secrets from here.
If it attempts to software-emulate a TPM a third party would be able to
verify that it wasn't manufactured by a "well-known" TPM manufacturer.
But these two limitations would also apply if the blue pill had used
VMX. 
	 
	[JC]  In the actual blue-pill attack, the hypervisor is
loaded/injected after (static) measurements have occured, so just using
a TPM and a static root of trust would not detect it.  Perhaps something
like IMA where every module and executable gets measured, in addition to
the boot chain, could but this is a very complex solution to implement
in practice.
	 
	Regarding this launch control policy, I've seen it mentioned
here and there but has it been documented yet? I haven't been able to
find much information on it in Intel's manuals but maybe it is in a
different manual? 
	 
	[JC]  TXT Launch Control Policy will be documented in the next
revision of the TXT spec.  In the meantime, the data structures and
processes can be seen in the lcptools code in the tboot project.
	 
	Best regards,
	 
	Martin Thiim

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

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

Hello,

thanks for your reply, my comments below:

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

I don't see how disabling VMX outside SMX adds any security, since full
virtualization is still possible in software, it just can't take advantage
of VMX. VMWare and others have offered "near native" virtualization
performance even before VMX. So it would still be possible to do a full (in
software) virtualization of the CPU, including SMX features, opening up for
a "blue-pill" attack. Of course, it wouldn't be possible to "fake" the PCR
registers on the true TPM so it wouldn't be able to extract any secrets from
here. If it attempts to software-emulate a TPM a third party would be able
to verify that it wasn't manufactured by a "well-known" TPM manufacturer.
But these two limitations would also apply if the blue pill had used VMX.

Regarding this launch control policy, I've seen it mentioned here and there
but has it been documented yet? I haven't been able to find much information
on it in Intel's manuals but maybe it is in a different manual?

Best regards,

Martin Thiim

Re: [tboot-devel] Infineon TPM reboot problem

[Cihula, J. <jos...@in...>]

On Monday, February 11, 2008 2:31 PM, Hiroshi Isozaki wrote:
> Hi all,
> 
> I have a very similar problem which David posted on Jan 14.
> Sorry for making a new thread, I just joined this mailing list.
> 
> The problem was the system reboots when GETSEC[SENTER] is executed.
> Even if I set policy into TPM NVRAM, it still reboots.
> 
> I am using infineon TPM chip (version 1.2.1.0). I made changes to the
source
> code along with the patch Hal posted on Jan 2 because I originally had
the
> same problem.  
> 
> My question is about the serial logs which David and Hal posted.
> I found these logs in the very beginning of the each log.
> TBOOT: TPM: get capability, return value = 00000000
> TBOOT: TPM: get nvindex size, return value = 00000000
> OR
> TBOOT: TPM: get capability, return value = 00000003
> TBOOT: TPM: get nvindex size, return value = 00000003
> 
> Although I checked the latest version of TBOOT source code
> (tboot-20071128.tar.gz), I could not find the above lines. Which
version are
> you using?  

This was added in rev 23 of the code, so it is not in the last tar file.
You can get the latest code using mercurial.

> I don' know this is a critical issue, but I just wanted to make sure
that I
> am using the correct version of code. 

If you are using the DQ35JO motherboard, the SENTER failure is a known
issue that will be fixed with a BIOS update shortly.

> 
> Kindest regards,
> Hiroshi Isozaki
> 
> 
>
------------------------------------------------------------------------
-
> 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

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

[Cihula, J. <jos...@in...>]

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

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

[Wei, G. <gan...@in...>]

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
	
	

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

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

[Wei, G. <gan...@in...>]

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

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

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

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?

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.

Best regards,

Martin Thiim

Re: [tboot-devel] tpm_unit_test_before_senter() ?

[Cihula, J. <jos...@in...>]

On Thursday, February 14, 2008 7:29 PM, Jun Koi wrote:
> On 2/15/08, Cihula, Joseph <jos...@in...> wrote:
>> On Thursday, February 14, 2008 3:30 AM, Jun Koi wrote:  > Hi,
>>  >
>>  > I am enjoying reading the tboot source code. I found that one of
the
>>  > first steps of tboot is to check some TPM functions. However, I
dont
>>  > understand the idea behind some tests, like in the function
>>  > tpm_unit_test_before_senter().
>>  >
>>  > Joseph, could you explain a bit about the motivation of those
tests?
>> 
>> 
>> The various test routines were used to validate that the TPM code was
>>  working correctly.
> 
> Is it necessary to do the test? Or we can suppose that if machine
> supports SINIT insn, TPM would work flawlessly?
> 
> Or did you see some malfunction TPM already?

The tests were to exercise the TPM code in tpm.c.  They are currently
#ifdef'ed out and so don't get run at all.

> 
> Thanks,
> Jun