tboot-devel — Developer support

Re: [tboot-devel] Infineon TPM problems and fixes

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

On Monday, January 07, 2008 6:04 PM, Wei, Gang wrote:
> Hal Finney <> scribbled on 2008-01-03 06:37 AM:
>=20
>> I tried launching tboot on my HP dc7800 vPro machine which uses an
>> Infineon TPM. It largely worked except that it got timeout errors
>> talking to the TPM. I did quite a bit of experimenting and found that
>> this TPM behaves a little differently than the code expects.
>=20
> Hal, thank you very much for your experimenting to figure out &
resolve
> TPM related issues in current TBOOT code.
>=20
>>=20
>> First, in tpm_wait_cmd_ready() the code expects the sts_valid bit in
>> the STS register to come on. However, this never happens. Apparently
>> Infineon feels that turning on the command_ready bit is enough of a
>> clue that the chip is ready to receive a command. After the first
>> write of data to the FIFO register, the sts_valid and expect bits do
>> come on as expected to indicate that the chip can accept more bytes,
>> but the code doesn't care at that point. I fixed this by patching the
>> code to ignore the failure of the sts_valid bit to appear, and just
>> proceed on.
>=20
> Seem like the Infineon TPM does not fully conform to TCG TPM SPEC, and
> your fix is acceptable.

According to my read of the spec, the stsValid bit does not need to be
set when querying the commandReady bit:
	stsValid
	This bit indicates that both TPM_STS_x.dataAvail and
TPM_STS_x.Expect are correct. If TPM_STS_x.stsValid is not set, then
TPM_STS_x.dataAvail and TPM_STS_x.Expect are not guaranteed to be
correct and software that is using TPM_STS_x.dataAvail or
TPM_STS_x.Expect must poll on TPM_STS_x register until
TPM_STS_x.stsValid is set. The TPM MUST set the TPM_STS_x.stsValid bit
within TIMEOUT_C after the last data cycle is received.

>> Then, I got timeouts in tpm_write_cmd_fifo(),  "wait for data
>> available timeout". This timeout happens after sending the command to
>> the chip and waiting for the response to appear. I notice that the
>> timeout counter, TPM_DATA_AVAIL_TIME_OUT, is only 0x100 which might
be
>> a little low. I increased it to 0x10000 and that fixed it. I didn't
>> take much time to try different values. Some commands like unseal or
>> key load can take a long time with some TPMs, like hundreds of
>> milliseconds; and of course keygen can take a minute or more. So this
>> timer either needs to be a lot bigger in general, or else the code
>> needs to be smart about how long various commands are expected to
>> take.
>=20
> Increasing TPM_DATA_AVAIL_TIME_OUT from 0x100 to 0x10000  can be a
> workaround so far. We may need a better timing mechanism in TBOOT for
> timeout.

Timeouts can be determined by calling TPM_GetCapability,
TPM_CAP_PROPERTY/TPM_CAP_PROP_TIS_TIMEOUT.  From the PC Client TPM Spec
you can then find out what operations each timeout applies to (by
searching).  We can probably use the default value (< 2s), but will need
to map it to the spin loop.

>> So with these two changes the tboot code appeared to work OK. I don't
>> actually have Xen installed so it dies at the end as expected, but it
>> does manage to launch the measured environment, talk to the TPM,
print
>> out and extend the various PCRs, and even seal some data
successfully.
>> It's nice to know that my TXT hardware is in working order!
>=20
> Your are lucky. And could you send out your patch for fixing Infineon
> issue and give us a chance to record your contribution to TBOOT
project?
>=20
>>=20
>> Hal Finney
>>=20
>=20
> Jimmy
>=20
>
------------------------------------------------------------------------
-
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
>
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketp
lace
> _______________________________________________
> tboot-devel mailing list
> tbo...@li...
> https://lists.sourceforge.net/lists/listinfo/tboot-devel

Re: [tboot-devel] Infineon TPM problems and fixes

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

Hal Finney <> scribbled on 2008-01-03 06:37 AM:

> I tried launching tboot on my HP dc7800 vPro machine which uses an
> Infineon TPM. It largely worked except that it got timeout errors
> talking to the TPM. I did quite a bit of experimenting and found that
> this TPM behaves a little differently than the code expects.

Hal, thank you very much for your experimenting to figure out & resolve
TPM related issues in current TBOOT code.

>=20
> First, in tpm_wait_cmd_ready() the code expects the sts_valid bit in
> the STS register to come on. However, this never happens. Apparently
> Infineon feels that turning on the command_ready bit is enough of a
> clue that the chip is ready to receive a command. After the first
> write of data to the FIFO register, the sts_valid and expect bits do
> come on as expected to indicate that the chip can accept more bytes,
> but the code doesn't care at that point. I fixed this by patching the
> code to ignore the failure of the sts_valid bit to appear, and just
> proceed on.

Seem like the Infineon TPM does not fully conform to TCG TPM SPEC, and
your fix is acceptable.

>=20
> Then, I got timeouts in tpm_write_cmd_fifo(),  "wait for data
> available timeout". This timeout happens after sending the command to
> the chip and waiting for the response to appear. I notice that the
> timeout counter, TPM_DATA_AVAIL_TIME_OUT, is only 0x100 which might be
> a little low. I increased it to 0x10000 and that fixed it. I didn't
> take much time to try different values. Some commands like unseal or
> key load can take a long time with some TPMs, like hundreds of
> milliseconds; and of course keygen can take a minute or more. So this
> timer either needs to be a lot bigger in general, or else the code
> needs to be smart about how long various commands are expected to
> take.

Increasing TPM_DATA_AVAIL_TIME_OUT from 0x100 to 0x10000  can be a
workaround so far. We may need a better timing mechanism in TBOOT for
timeout.

>=20
> So with these two changes the tboot code appeared to work OK. I don't
> actually have Xen installed so it dies at the end as expected, but it
> does manage to launch the measured environment, talk to the TPM, print
> out and extend the various PCRs, and even seal some data successfully.
> It's nice to know that my TXT hardware is in working order!

Your are lucky. And could you send out your patch for fixing Infineon
issue and give us a chance to record your contribution to TBOOT project?

>=20
> Hal Finney
>=20

Jimmy

Re: [tboot-devel] SINIT question

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

I've just gotten back from vacation, so sorry for the delay.  I think
that I can address all of your questions/issues.

As Jeff said, your chipset/motherboard requires the bwr_ version of
SINIT.  This was our first TXT-capable chipset and was only available in
very limited production systems from MPC and in our SDPs.  It does not
support LCP, VT-d, etc.  You really should either switch to a newer
commercial TXT-capable system or one of our Weybridge SDPs, both based
on the ICH9 chipset (the SINIT for which is on the tboot site).

Appendix A of the spec has some fields that are only in the ICH9+
versions of AC Modules (i.e. not in the bwr_ version)--it is an error on
our part that we didn't call this out and note them.

As for the multiple cores, Hal was right--the chipset has a mechanism to
determine how many cores are in the system and the SENTER process will
spin until all detected cores acknowledge the SENTER.  So if BIOS lets
the to-be-disabled core execute some code before it disables the core
then the chipset will detect it and SENTER will hang.

I hope this helps and if you have any further questions, please feel
free to post again.

Joe

On Sunday, December 16, 2007 9:36 PM, Emil Meng wrote:
> Hello Shane,
>=20
> Thank you very much for your reply. We received this machine a long
> time ago, but haven't worked with it in depth until recently.
>=20
> [Jeff] recommends that I switch to a Bearlake board, but considering
> cost and timing issues, this may not be a possibility in the near
> future. Is there any indication that more updates to ICH8 (or in
> particular, my board) will be released in the future?
>=20
> Thank you very much for all the information on this mailing list! It's
> been a great resource for everybody, and especially us students in
> academia.
>=20
> -emil
>=20
> On Dec 17, 2007 11:05 AM, Wang, Shane <sha...@in...> wrote:
>> Hi Emil,
>>=20
>> These are some answers from one of my Intel colleagues. (see below)
>> Wish this will help you. For question 2, please be patient to wait
for
>> response from the other colleague of mine.
>>=20
>> Thanks.
>> Shane
>>=20
>>=20
>> Hal Finney wrote:
>>> Hello Emil - I had exchanged some email with Joe Cihula a few days
ago
>>> and at that time he said he was leaving on vacation and would not be
>>> back until the 2nd week of January. So unfortunately he may not be
>>> able to respond to your questions for some time. I don't know if
>>> anyone else from Intel monitors this mailing list.
>>>=20
>>> I have a couple of comments although I am afraid I can't be much
help:
>>>=20
>>> On Dec 13, 2007 7:46 PM, Emil Meng <me...@os...>
>>> wrote:
>>>> I have a quick question regarding the SINIT module.
>>>>=20
>>>> I am currently creating a proof-of-concept of a VMM which can be
>>>> securely late-launched multiple times. The VMM itself is very
similar
>>>> in design to Intel's LVMM, and I am in the process of getting it to
>>>> be launched through tboot, but am having a few problems with SINIT
>>>> executing properly.
>>>=20
>>> I am aiming to do something similar but am not so far along and have
>>> not yet gotten to the point where I can do a GETSEC[SENTER].
>>>=20
>>>> I have the "Intel Desktop Board DQ965CO" which i believe is in the
>>>> ICH8 family, and with the board came the following SINIT module:
>>>> filename: bwr_sinit_20060922_release.bin
>>>> sha1sum: 8ad582e50be40df7da9c1b8db6ed77499e920613
>>>=20
>>> That's interesting, I did not realize that Intel made a motherboard
>>> that supported TXT. It's encouraging to see that they are getting
this
>>> technology into people's hands.
>>>=20
>>>> Also I have downloaded the SINIT offered from the tboot package:
>>>> filename: BRLK_SINIT_20070910_release.BIN
>>>> sha1sum: 46f4e1c199c2983e8a8a115cd90c88353e7b08dc
>>>>=20
>>>> My questions are:
>>>>=20
>>>> 1. Should I be able to use either of the SINIT modules for my
>>>> hardware, or are they specific to a certain chipset?
>> [Jeff] AC modules are specific to a chipset.  The bwr one is the one
>> that supports the board mentioned.
>>=20
>>=20
>>>=20
>>> According to the TXT Preliminary Architectural Specification, the
>>> SINIT module contains a table that indicates which chipsets it
>>> supports. The format of this table is described in Tables 17-19 in
>>> Appendix A.1. Dumping out the relevant data from
>>> BRLK_SINIT_20070910_release.BIN reveals:
>>>=20
>>> 0004c0 cd d6 24 80 33 47 62 2a d1 f1 3a 89 3b 11 82 bc
>>> 0004d0 01 02 20 00 e0 04 00 00 03 00 00 00 01 00 01 00
>>> 0004e0 01 00 00 00 01 00 00 00 86 80 01 80 07 00 00 00
>>>=20
>>> The first line is the UUIDs described in Table 17. The "e0 04" of
the
>>> 2nd line means that the supported chipset ID list starts at offset
>>> 4e0, which is the 3rd line. The 01 00 00 00 at the start means that
>>> there is just one chipset ID supported by this AC module. The
>>> remaining entries indicate that the module supports chipsets with
>>> vendor ID 8086, device ID 8001 and revisionID must have one or more
>>> bits set that match the 0007 mask. This should then be compared with
>>> the LT.DIDVID TXT configuration register. My DIDVID register reads
as
>>> 780018086 so that matches this module.
>>>=20
>>>=20
>>>> 1b. If they are chipset specific, where can I get the latest
version
>>>> of SINIT for my particular chipset?
>> [Jeff] The one you have is the last one we had done for that chipset.
>> Many changes in the ACMs have occurred since then.  I would recommend
>> getting one of the Bearlake boards that has TXT capability as not all
>> Bearlake boards have this.=20
>>=20
>>=20
>>>=20
>>> For that you will have to wait for someone from Intel I think.
>>>=20
>>>> 2. In order to make the proof-of-concept easier to develop and
debug,
>>>> I disabled one of the cores for the time being. However, with a
core
>>>> disabled, neither of the SINIT modules listed above would execute
>>>> properly. (actually, the one offered on the tboot website doesn't
>>>> boot at all under any circumstance) What happens is that tboot goes
>>>> through its first pass, confirms that the SINIT is correct, and
then
>>>> attempts to execute GETSEC[SENTER]. However, it never returns to
>>>> tboot for the second pass. If I turn both cores on, the
>>>> bwr_sinit_20060922_release.bin SINIT will at least get back to
tboot,
>>>> and go through a second pass. So here's my question:
>>>>=20
>>>> Does SINIT require multiple cores to be enabled in order for it to
>>>> work properly?
>>>=20
>>> The only thing I can suggest here is that after a failure, you can
>>> reboot and then read the LT.ERRORCODE register. The Sourceforge
>>> download package for the SINIT module includes a table of failure
and
>>> progress codes that get stored in this register by SINIT as it runs.
>>> By relating the progress/error code to the information in the file
>>> from the SINIT download package it might shed light on where things
>>> are going wrong. See also Table 23 in Appendix B of the Arch. spec,
>>> which shows error codes in case it does not get to the point of
running the
>>> SINIT module.=20
>>>=20
>>> Sorry I cannot be more help, this technology is very new to me too.
I
>>> hope to have more time over the holidays to get my experiments going
-
>>> just got my machine (HP dc7800) last week -
>>>=20
>>> Hal Finney
>>>=20
>>>=20
>>
------------------------------------------------------------------------
>> -
>>> SF.Net email is sponsored by:
>>> Check out the new SourceForge.net Marketplace.
>>> It's the best place to buy or sell services
>>> for just about anything Open Source.
>>>=20
>>
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketp
>> lace
>>> _______________________________________________
>>> tboot-devel mailing list
>>> tbo...@li...
>>> https://lists.sourceforge.net/lists/listinfo/tboot-devel
>>=20
>>=20
>=20
>
------------------------------------------------------------------------
-
> SF.Net email is sponsored by:
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services
> for just about anything Open Source.
>
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketp
lace
> _______________________________________________
> tboot-devel mailing list
> tbo...@li...
> https://lists.sourceforge.net/lists/listinfo/tboot-devel

Re: [tboot-devel] Failure to run MLE at non-zero linear address

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

Replying to myself, but I solved the problem. The line:

>    pte = pg_tab + MLE_OFFSET/PAGE_SIZE;

was wrong, because pg_tab is a void * and I wrongly assumed it was a
uint64_t *. So I fixed it with a case:

pte = (uint64_t *)pg_tab + MLE_OFFSET/PAGE_SIZE;

With this, it worked and I am now able to load the MLE at a non-zero
linear address. (Of course it still does not turn on paging so this
address space is used only for computing the MLE hash.)

Hal

[tboot-devel] Failure to run MLE at non-zero linear address

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

I am experimenting with tboot as a model for other TXT code. It is
great to have something that works as a starting point.

As a first small step, I am trying to change tboot so that the MLE
page tables are set up with the MLE at a nonzero linear address. The
spec says that this should work. Presently the MLE is mapped in the
page tables at address 0 - 16000 (hex). I want to first try changing
this to map at 1000-17000, in other words just one page higher.

Here is the patch I made to txt.c for this:

$ hg diff txt/txt.c
diff -r 201092e1f7e9 tboot/txt/txt.c
--- a/tboot/txt/txt.c   Thu Nov 22 11:08:37 2007 -0500
+++ b/tboot/txt/txt.c   Fri Jan 04 09:40:11 2008 -0800
@@ -74,6 +74,9 @@ extern char __start[];          /* tboot
 extern char __start[];          /* tboot entry point in boot.S */
 extern char _txt_wakeup[];      /* RLP join address for GETSEC[WAKEUP] */

+/* Offset within page tables */
+#define MLE_OFFSET     0x1000
+
 /*
  * this is the structure whose addr we'll put in TXT heap
  * it needs to be within the MLE pages, so force it to the .text section
@@ -83,8 +86,8 @@ __attribute__ ((__section__ (".text")))
     guid              :  MLE_HDR_GUID,
     length            :  sizeof(mle_hdr_t),
     version           :  0x00010001,
-    entry_point       :  (uint32_t)&__start - TBOOT_BASE_ADDR,
-    first_valid_page  :  0,
+    entry_point       :  (uint32_t)&__start - TBOOT_BASE_ADDR + MLE_OFFSET,
+    first_valid_page  :  MLE_OFFSET,
     mle_start_off     :  (uint32_t)&_mle_start - TBOOT_BASE_ADDR,
     mle_end_off       :  (uint32_t)&_mle_end - TBOOT_BASE_ADDR,
 };
@@ -168,7 +171,7 @@ static void *build_mle_pagetable(uint32_
     /* only use first entry in page dir */
     *(uint64_t *)pg_dir = MAKE_PDTE(pg_tab);

-    pte = pg_tab;
+    pte = pg_tab + MLE_OFFSET/PAGE_SIZE;
     mle_off = 0;
     do {
         *pte = MAKE_PDTE(mle_start + mle_off);
@@ -305,7 +308,8 @@ static txt_heap_t *init_txt_heap(void *p
     os_sinit_data->mle_ptab = (uint64_t)(unsigned long)ptab_base;
     os_sinit_data->mle_size = g_mle_hdr.mle_end_off - g_mle_hdr.mle_start_off;
     /* this is linear addr (offset from MLE base) of mle header */
-    os_sinit_data->mle_hdr_base = (uint64_t)&g_mle_hdr - (uint64_t)&_mle_start;
+    os_sinit_data->mle_hdr_base =
+       (uint64_t)&g_mle_hdr - (uint64_t)&_mle_start + MLE_OFFSET;
     /* SINIT supports more recent version than we do, so use our most recent */
     if ( os_sinit_data_ver >= 0x03 ) {
         os_sinit_data->version = 0x03;     /* 0x03 is the max we support */


Basically I make 4 changes: entry_point and first_valid_page in the
MLE header get moved up 0x1000, and the mle_hdr_base field in the TXT
heap also gets moved up. Then the page tables are initialized starting
with the 2nd rather than the 1st entry.

However, it does not work. The system crashes with a TXT reset when it
calls GETSEC[SENTER]. And due to some problem with my HP dc7800 vPro
system, TXT resets don't lead to a clean reboot and I have to
power-cycle my machine, losing any ERRORCODE status. So I can't tell
what exactly is going wrong.

I wonder if someone with more experience with TXT can advise me
whether other fields need to be adjusted when changing the linear
address mapping in the MLE page tables

Also, along these lines, the documentation is ambiguous about the MLE
Join structure EIP address. Table 7 says, "Linear IP entry point
(physical address)". However a linear address is not a physical
address. tboot is actually putting in the physical address here so I
assume the reference to a linear address is a mistake. The issue
doesn't affect my test because I am not getting that far, but since
tboot works OK with a physical address, I assume that there is no need
to adjust this value when changing the MLE page tables.

Thanks very much!

Hal Finney

[tboot-devel] Infineon TPM problems and fixes

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

I tried launching tboot on my HP dc7800 vPro machine which uses an
Infineon TPM. It largely worked except that it got timeout errors
talking to the TPM. I did quite a bit of experimenting and found that
this TPM behaves a little differently than the code expects.

First, in tpm_wait_cmd_ready() the code expects the sts_valid bit in
the STS register to come on. However, this never happens. Apparently
Infineon feels that turning on the command_ready bit is enough of a
clue that the chip is ready to receive a command. After the first
write of data to the FIFO register, the sts_valid and expect bits do
come on as expected to indicate that the chip can accept more bytes,
but the code doesn't care at that point. I fixed this by patching the
code to ignore the failure of the sts_valid bit to appear, and just
proceed on.

Then, I got timeouts in tpm_write_cmd_fifo(),  "wait for data
available timeout". This timeout happens after sending the command to
the chip and waiting for the response to appear. I notice that the
timeout counter, TPM_DATA_AVAIL_TIME_OUT, is only 0x100 which might be
a little low. I increased it to 0x10000 and that fixed it. I didn't
take much time to try different values. Some commands like unseal or
key load can take a long time with some TPMs, like hundreds of
milliseconds; and of course keygen can take a minute or more. So this
timer either needs to be a lot bigger in general, or else the code
needs to be smart about how long various commands are expected to
take.

So with these two changes the tboot code appeared to work OK. I don't
actually have Xen installed so it dies at the end as expected, but it
does manage to launch the measured environment, talk to the TPM, print
out and extend the various PCRs, and even seal some data successfully.
It's nice to know that my TXT hardware is in working order!

Hal Finney

Re: [tboot-devel] SINIT question

[Emil M. <me...@os...>]

Hello Shane,

Thank you very much for your reply. We received this machine a long
time ago, but haven't worked with it in depth until recently.

[Jeff] recommends that I switch to a Bearlake board, but considering
cost and timing issues, this may not be a possibility in the near
future. Is there any indication that more updates to ICH8 (or in
particular, my board) will be released in the future?

Thank you very much for all the information on this mailing list! It's
been a great resource for everybody, and especially us students in
academia.

-emil

On Dec 17, 2007 11:05 AM, Wang, Shane <sha...@in...> wrote:
> Hi Emil,
>
> These are some answers from one of my Intel colleagues. (see below)
> Wish this will help you. For question 2, please be patient to wait for
> response from the other colleague of mine.
>
> Thanks.
> Shane
>
>
> Hal Finney wrote:
> > Hello Emil - I had exchanged some email with Joe Cihula a few days ago
> > and at that time he said he was leaving on vacation and would not be
> > back until the 2nd week of January. So unfortunately he may not be
> > able to respond to your questions for some time. I don't know if
> > anyone else from Intel monitors this mailing list.
> >
> > I have a couple of comments although I am afraid I can't be much help:
> >
> > On Dec 13, 2007 7:46 PM, Emil Meng <me...@os...>
> > wrote:
> >> I have a quick question regarding the SINIT module.
> >>
> >> I am currently creating a proof-of-concept of a VMM which can be
> >> securely late-launched multiple times. The VMM itself is very similar
> >> in design to Intel's LVMM, and I am in the process of getting it to
> >> be launched through tboot, but am having a few problems with SINIT
> >> executing properly.
> >
> > I am aiming to do something similar but am not so far along and have
> > not yet gotten to the point where I can do a GETSEC[SENTER].
> >
> >> I have the "Intel Desktop Board DQ965CO" which i believe is in the
> >> ICH8 family, and with the board came the following SINIT module:
> >> filename: bwr_sinit_20060922_release.bin
> >> sha1sum: 8ad582e50be40df7da9c1b8db6ed77499e920613
> >
> > That's interesting, I did not realize that Intel made a motherboard
> > that supported TXT. It's encouraging to see that they are getting this
> > technology into people's hands.
> >
> >> Also I have downloaded the SINIT offered from the tboot package:
> >> filename: BRLK_SINIT_20070910_release.BIN
> >> sha1sum: 46f4e1c199c2983e8a8a115cd90c88353e7b08dc
> >>
> >> My questions are:
> >>
> >> 1. Should I be able to use either of the SINIT modules for my
> >> hardware, or are they specific to a certain chipset?
> [Jeff] AC modules are specific to a chipset.  The bwr one is the one
> that supports the board mentioned.
>
>
> >
> > According to the TXT Preliminary Architectural Specification, the
> > SINIT module contains a table that indicates which chipsets it
> > supports. The format of this table is described in Tables 17-19 in
> > Appendix A.1. Dumping out the relevant data from
> > BRLK_SINIT_20070910_release.BIN reveals:
> >
> > 0004c0 cd d6 24 80 33 47 62 2a d1 f1 3a 89 3b 11 82 bc
> > 0004d0 01 02 20 00 e0 04 00 00 03 00 00 00 01 00 01 00
> > 0004e0 01 00 00 00 01 00 00 00 86 80 01 80 07 00 00 00
> >
> > The first line is the UUIDs described in Table 17. The "e0 04" of the
> > 2nd line means that the supported chipset ID list starts at offset
> > 4e0, which is the 3rd line. The 01 00 00 00 at the start means that
> > there is just one chipset ID supported by this AC module. The
> > remaining entries indicate that the module supports chipsets with
> > vendor ID 8086, device ID 8001 and revisionID must have one or more
> > bits set that match the 0007 mask. This should then be compared with
> > the LT.DIDVID TXT configuration register. My DIDVID register reads as
> > 780018086 so that matches this module.
> >
> >
> >> 1b. If they are chipset specific, where can I get the latest version
> >> of SINIT for my particular chipset?
> [Jeff] The one you have is the last one we had done for that chipset.
> Many changes in the ACMs have occurred since then.  I would recommend
> getting one of the Bearlake boards that has TXT capability as not all
> Bearlake boards have this.
>
>
> >
> > For that you will have to wait for someone from Intel I think.
> >
> >> 2. In order to make the proof-of-concept easier to develop and debug,
> >> I disabled one of the cores for the time being. However, with a core
> >> disabled, neither of the SINIT modules listed above would execute
> >> properly. (actually, the one offered on the tboot website doesn't
> >> boot at all under any circumstance) What happens is that tboot goes
> >> through its first pass, confirms that the SINIT is correct, and then
> >> attempts to execute GETSEC[SENTER]. However, it never returns to
> >> tboot for the second pass. If I turn both cores on, the
> >> bwr_sinit_20060922_release.bin SINIT will at least get back to tboot,
> >> and go through a second pass. So here's my question:
> >>
> >> Does SINIT require multiple cores to be enabled in order for it to
> >> work properly?
> >
> > The only thing I can suggest here is that after a failure, you can
> > reboot and then read the LT.ERRORCODE register. The Sourceforge
> > download package for the SINIT module includes a table of failure and
> > progress codes that get stored in this register by SINIT as it runs.
> > By relating the progress/error code to the information in the file
> > from the SINIT download package it might shed light on where things
> > are going wrong. See also Table 23 in Appendix B of the Arch. spec,
> > which shows error codes in case it does not get to the point of
> > running the SINIT module.
> >
> > Sorry I cannot be more help, this technology is very new to me too. I
> > hope to have more time over the holidays to get my experiments going -
> > just got my machine (HP dc7800) last week -
> >
> > Hal Finney
> >
> >
> ------------------------------------------------------------------------
> -
> > SF.Net email is sponsored by:
> > Check out the new SourceForge.net Marketplace.
> > It's the best place to buy or sell services
> > for just about anything Open Source.
> >
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketp
> lace
> > _______________________________________________
> > tboot-devel mailing list
> > tbo...@li...
> > https://lists.sourceforge.net/lists/listinfo/tboot-devel
>
>

Re: [tboot-devel] SINIT question

[Emil M. <me...@os...>]

Hello Hal,

Thank you very much for your reply. Your insights into my questions
are really helpful, and I have dug a bit more into it and thought I
would share my findings.

On Dec 14, 2007 2:51 PM, Hal Finney <hal...@gm...> wrote:
> Hello Emil - I had exchanged some email with Joe Cihula a few days ago
> and at that time he said he was leaving on vacation and would not be
> back until the 2nd week of January. So unfortunately he may not be
> able to respond to your questions for some time. I don't know if
> anyone else from Intel monitors this mailing list.
>
> I have a couple of comments although I am afraid I can't be much help:
>
> On Dec 13, 2007 7:46 PM, Emil Meng <me...@os...> wrote:
> > I have a quick question regarding the SINIT module.
> >
> > I am currently creating a proof-of-concept of a VMM which can be
> > securely late-launched multiple times. The VMM itself is very similar
> > in design to Intel's LVMM, and I am in the process of getting it to be
> > launched through tboot, but am having a few problems with SINIT
> > executing properly.
>
> I am aiming to do something similar but am not so far along and have
> not yet gotten to the point where I can do a GETSEC[SENTER].
>

A quick question of curiosity, are you attempting to rewrite the
existing TBOOT code to achieve your goasl, or are you rewriting it
from scratch, or perhaps doing something else entirely?

> > I have the "Intel Desktop Board DQ965CO" which i believe is in the
> > ICH8 family, and with the board came the following SINIT module:
> > filename: bwr_sinit_20060922_release.bin
> > sha1sum: 8ad582e50be40df7da9c1b8db6ed77499e920613
>
> That's interesting, I did not realize that Intel made a motherboard
> that supported TXT. It's encouraging to see that they are getting this
> technology into people's hands.
>
> > Also I have downloaded the SINIT offered from the tboot package:
> > filename: BRLK_SINIT_20070910_release.BIN
> > sha1sum: 46f4e1c199c2983e8a8a115cd90c88353e7b08dc
> >
> > My questions are:
> >
> > 1. Should I be able to use either of the SINIT modules for my
> > hardware, or are they specific to a certain chipset?
>
> According to the TXT Preliminary Architectural Specification, the
> SINIT module contains a table that indicates which chipsets it
> supports. The format of this table is described in Tables 17-19 in
> Appendix A.1. Dumping out the relevant data from
> BRLK_SINIT_20070910_release.BIN reveals:
>
> 0004c0 cd d6 24 80 33 47 62 2a d1 f1 3a 89 3b 11 82 bc
> 0004d0 01 02 20 00 e0 04 00 00 03 00 00 00 01 00 01 00
> 0004e0 01 00 00 00 01 00 00 00 86 80 01 80 07 00 00 00
>
> The first line is the UUIDs described in Table 17. The "e0 04" of the
> 2nd line means that the supported chipset ID list starts at offset
> 4e0, which is the 3rd line. The 01 00 00 00 at the start means that
> there is just one chipset ID supported by this AC module. The
> remaining entries indicate that the module supports chipsets with
> vendor ID 8086, device ID 8001 and revisionID must have one or more
> bits set that match the 0007 mask. This should then be compared with
> the LT.DIDVID TXT configuration register. My DIDVID register reads as
> 780018086 so that matches this module.

My bwr_sinit_20060922_release.bin has a User Area space that begins:
00004c0 0101 0008 04c8 0000 0001 0000 0001 0000
00004d0 8086 8000 0001 0000 0000 0000 0000 0000
00004e0 0000 0000 0000 0000 ffff 0000 9b00 00cf
00004f0 ffff 0000 9300 00cf ffff 0000 9300 00cf

Now, this seems a bit off... as if it doesn't match the specification
published bin the "Intel Trusted Execution Technology - Preliminary
Architecture Specification"

First, the 16 byte UUID seems like it has quite a few too many 0's.
Now, I suppose that this isn't really a problem, if it is really a
UUID, but it seems as if my User space doesn't have a UUID, and
everything is offset by the missing 16 bytes. If this is the case, I
haven't thought out all the consequences, but my foremost concern is
that the specification published does not match my chipset and that it
is much too outdated.

My DIDVID register reads:
LT.DIDVID:00000001 80008086

So I guess i'm running revision 1. Once again, probably confirming
that i'm using an outdated machine.

>
>
> > 1b. If they are chipset specific, where can I get the latest version
> > of SINIT for my particular chipset?
>
> For that you will have to wait for someone from Intel I think.
>
> > 2. In order to make the proof-of-concept easier to develop and debug,
> > I disabled one of the cores for the time being. However, with a core
> > disabled, neither of the SINIT modules listed above would execute
> > properly. (actually, the one offered on the tboot website doesn't boot
> > at all under any circumstance) What happens is that tboot goes through
> > its first pass, confirms that the SINIT is correct, and then attempts
> > to execute GETSEC[SENTER]. However, it never returns to tboot for the
> > second pass. If I turn both cores on, the
> > bwr_sinit_20060922_release.bin SINIT will at least get back to tboot,
> > and go through a second pass. So here's my question:
> >
> > Does SINIT require multiple cores to be enabled in order for it to
> > work properly?
>
> The only thing I can suggest here is that after a failure, you can
> reboot and then read the LT.ERRORCODE register. The Sourceforge
> download package for the SINIT module includes a table of failure and
> progress codes that get stored in this register by SINIT as it runs.
> By relating the progress/error code to the information in the file
> from the SINIT download package it might shed light on where things
> are going wrong. See also Table 23 in Appendix B of the Arch. spec,
> which shows error codes in case it does not get to the point of
> running the SINIT module.

I've gone ahead and tried the experiment, and received unpromising
results. I went ahead and attempted to boot via TBOOT my machine with
multiple cores disabled via the BIOS. TBOOT gets to the point where it
executes the GETSEC[SENTER], but appears to do nothing useful
afterwards. It just hangs, and I cannot say for sure whether or not
the machine is unresponsive... just that it doesn't do anything
useful. I reset the machine via a hardware reset switch and attempt to
boot TBOOT again (where the TXT public registers are outputted,
looking to get a meaningful error code). This is what I get:

TBOOT: TXT public config registers:
TBOOT:               LT.STS:00000000 00000052
TBOOT:         LT.ERRORCODE:00000000 00000000
TBOOT:            LT.DIDVID:00000001 80008086
TBOOT:        LT.SINIT.BASE:00000000 7D800000
TBOOT:        LT.SINIT.SIZE:00000000 00020000
TBOOT:          LT.MLE.JOIN:00000000 00000000
TBOOT:         LT.HEAP.BASE:00000000 7D820000
TBOOT:         LT.HEAP.SIZE:00000000 001E0000
TBOOT:             LT.E2STS:00000000 00000010

LT.ERRORCODE is shown to be an entirely cleared register, which is
quite concerning. I'm not sure if this is because it is a revision 1
chipset/platform, or if it really didn't fail. Any help or insight
into this would be greatly appreciated.

Re: [tboot-devel] SINIT question

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

Hi Emil,

These are some answers from one of my Intel colleagues. (see below)=20
Wish this will help you. For question 2, please be patient to wait for=20
response from the other colleague of mine.

Thanks.
Shane

Hal Finney wrote:
> Hello Emil - I had exchanged some email with Joe Cihula a few days ago
> and at that time he said he was leaving on vacation and would not be
> back until the 2nd week of January. So unfortunately he may not be
> able to respond to your questions for some time. I don't know if
> anyone else from Intel monitors this mailing list.
>=20
> I have a couple of comments although I am afraid I can't be much help:
>=20
> On Dec 13, 2007 7:46 PM, Emil Meng <me...@os...>
> wrote:=20
>> I have a quick question regarding the SINIT module.
>>=20
>> I am currently creating a proof-of-concept of a VMM which can be
>> securely late-launched multiple times. The VMM itself is very similar
>> in design to Intel's LVMM, and I am in the process of getting it to
>> be launched through tboot, but am having a few problems with SINIT
>> executing properly.
>=20
> I am aiming to do something similar but am not so far along and have
> not yet gotten to the point where I can do a GETSEC[SENTER].
>=20
>> I have the "Intel Desktop Board DQ965CO" which i believe is in the
>> ICH8 family, and with the board came the following SINIT module:
>> filename: bwr_sinit_20060922_release.bin
>> sha1sum: 8ad582e50be40df7da9c1b8db6ed77499e920613
>=20
> That's interesting, I did not realize that Intel made a motherboard
> that supported TXT. It's encouraging to see that they are getting this
> technology into people's hands.
>=20
>> Also I have downloaded the SINIT offered from the tboot package:
>> filename: BRLK_SINIT_20070910_release.BIN
>> sha1sum: 46f4e1c199c2983e8a8a115cd90c88353e7b08dc
>>=20
>> My questions are:
>>=20
>> 1. Should I be able to use either of the SINIT modules for my
>> hardware, or are they specific to a certain chipset?
[Jeff] AC modules are specific to a chipset.  The bwr one is the one
that supports the board mentioned. =20


>=20
> According to the TXT Preliminary Architectural Specification, the
> SINIT module contains a table that indicates which chipsets it
> supports. The format of this table is described in Tables 17-19 in
> Appendix A.1. Dumping out the relevant data from
> BRLK_SINIT_20070910_release.BIN reveals:
>=20
> 0004c0 cd d6 24 80 33 47 62 2a d1 f1 3a 89 3b 11 82 bc
> 0004d0 01 02 20 00 e0 04 00 00 03 00 00 00 01 00 01 00
> 0004e0 01 00 00 00 01 00 00 00 86 80 01 80 07 00 00 00
>=20
> The first line is the UUIDs described in Table 17. The "e0 04" of the
> 2nd line means that the supported chipset ID list starts at offset
> 4e0, which is the 3rd line. The 01 00 00 00 at the start means that
> there is just one chipset ID supported by this AC module. The
> remaining entries indicate that the module supports chipsets with
> vendor ID 8086, device ID 8001 and revisionID must have one or more
> bits set that match the 0007 mask. This should then be compared with
> the LT.DIDVID TXT configuration register. My DIDVID register reads as
> 780018086 so that matches this module.
>=20
>=20
>> 1b. If they are chipset specific, where can I get the latest version
>> of SINIT for my particular chipset?
[Jeff] The one you have is the last one we had done for that chipset.
Many changes in the ACMs have occurred since then.  I would recommend
getting one of the Bearlake boards that has TXT capability as not all
Bearlake boards have this.

>=20
> For that you will have to wait for someone from Intel I think.
>=20
>> 2. In order to make the proof-of-concept easier to develop and debug,
>> I disabled one of the cores for the time being. However, with a core
>> disabled, neither of the SINIT modules listed above would execute
>> properly. (actually, the one offered on the tboot website doesn't
>> boot at all under any circumstance) What happens is that tboot goes
>> through its first pass, confirms that the SINIT is correct, and then
>> attempts to execute GETSEC[SENTER]. However, it never returns to
>> tboot for the second pass. If I turn both cores on, the
>> bwr_sinit_20060922_release.bin SINIT will at least get back to tboot,
>> and go through a second pass. So here's my question:
>>=20
>> Does SINIT require multiple cores to be enabled in order for it to
>> work properly?
>=20
> The only thing I can suggest here is that after a failure, you can
> reboot and then read the LT.ERRORCODE register. The Sourceforge
> download package for the SINIT module includes a table of failure and
> progress codes that get stored in this register by SINIT as it runs.
> By relating the progress/error code to the information in the file
> from the SINIT download package it might shed light on where things
> are going wrong. See also Table 23 in Appendix B of the Arch. spec,
> which shows error codes in case it does not get to the point of
> running the SINIT module.
>=20
> Sorry I cannot be more help, this technology is very new to me too. I
> hope to have more time over the holidays to get my experiments going -
> just got my machine (HP dc7800) last week -
>=20
> Hal Finney
>=20
>
------------------------------------------------------------------------
-
> SF.Net email is sponsored by:
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services
> for just about anything Open Source.
>
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketp
lace
> _______________________________________________
> tboot-devel mailing list
> tbo...@li...
> https://lists.sourceforge.net/lists/listinfo/tboot-devel

Re: [tboot-devel] SINIT question

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

Hi Emil, I had another idea about your question:

On Dec 13, 2007 7:46 PM, Emil Meng <me...@os...> wrote:
> 2. In order to make the proof-of-concept easier to develop and debug,
> I disabled one of the cores for the time being. However, with a core
> disabled, neither of the SINIT modules listed above would execute
> properly. (actually, the one offered on the tboot website doesn't boot
> at all under any circumstance) What happens is that tboot goes through
> its first pass, confirms that the SINIT is correct, and then attempts
> to execute GETSEC[SENTER]. However, it never returns to tboot for the
> second pass. If I turn both cores on, the
> bwr_sinit_20060922_release.bin SINIT will at least get back to tboot,
> and go through a second pass. So here's my question:
>
> Does SINIT require multiple cores to be enabled in order for it to
> work properly?

It's possible that disabling the core (in BIOS?) does not fully remove
awareness of that core from all parts of the architecture. If so then
the GETSEC[SENTER] instruction may still be expecting the other core
to have been set up according to rules. For example the MTRRs are
supposed to be the same in all cores. By disabling the other cores,
this setup is probably not happening, so if SENTER is still checking
for consistency that could cause it to fail. It depends on how the
other cores are disabled and whether that will convince SENTER not to
pay attention to them.

Just a thought you might want to consider -

Hal

Re: [tboot-devel] SINIT question

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

Hello Emil - I had exchanged some email with Joe Cihula a few days ago
and at that time he said he was leaving on vacation and would not be
back until the 2nd week of January. So unfortunately he may not be
able to respond to your questions for some time. I don't know if
anyone else from Intel monitors this mailing list.

I have a couple of comments although I am afraid I can't be much help:

On Dec 13, 2007 7:46 PM, Emil Meng <me...@os...> wrote:
> I have a quick question regarding the SINIT module.
>
> I am currently creating a proof-of-concept of a VMM which can be
> securely late-launched multiple times. The VMM itself is very similar
> in design to Intel's LVMM, and I am in the process of getting it to be
> launched through tboot, but am having a few problems with SINIT
> executing properly.

I am aiming to do something similar but am not so far along and have
not yet gotten to the point where I can do a GETSEC[SENTER].

> I have the "Intel Desktop Board DQ965CO" which i believe is in the
> ICH8 family, and with the board came the following SINIT module:
> filename: bwr_sinit_20060922_release.bin
> sha1sum: 8ad582e50be40df7da9c1b8db6ed77499e920613

That's interesting, I did not realize that Intel made a motherboard
that supported TXT. It's encouraging to see that they are getting this
technology into people's hands.

> Also I have downloaded the SINIT offered from the tboot package:
> filename: BRLK_SINIT_20070910_release.BIN
> sha1sum: 46f4e1c199c2983e8a8a115cd90c88353e7b08dc
>
> My questions are:
>
> 1. Should I be able to use either of the SINIT modules for my
> hardware, or are they specific to a certain chipset?

According to the TXT Preliminary Architectural Specification, the
SINIT module contains a table that indicates which chipsets it
supports. The format of this table is described in Tables 17-19 in
Appendix A.1. Dumping out the relevant data from
BRLK_SINIT_20070910_release.BIN reveals:

0004c0 cd d6 24 80 33 47 62 2a d1 f1 3a 89 3b 11 82 bc
0004d0 01 02 20 00 e0 04 00 00 03 00 00 00 01 00 01 00
0004e0 01 00 00 00 01 00 00 00 86 80 01 80 07 00 00 00

The first line is the UUIDs described in Table 17. The "e0 04" of the
2nd line means that the supported chipset ID list starts at offset
4e0, which is the 3rd line. The 01 00 00 00 at the start means that
there is just one chipset ID supported by this AC module. The
remaining entries indicate that the module supports chipsets with
vendor ID 8086, device ID 8001 and revisionID must have one or more
bits set that match the 0007 mask. This should then be compared with
the LT.DIDVID TXT configuration register. My DIDVID register reads as
780018086 so that matches this module.


> 1b. If they are chipset specific, where can I get the latest version
> of SINIT for my particular chipset?

For that you will have to wait for someone from Intel I think.

> 2. In order to make the proof-of-concept easier to develop and debug,
> I disabled one of the cores for the time being. However, with a core
> disabled, neither of the SINIT modules listed above would execute
> properly. (actually, the one offered on the tboot website doesn't boot
> at all under any circumstance) What happens is that tboot goes through
> its first pass, confirms that the SINIT is correct, and then attempts
> to execute GETSEC[SENTER]. However, it never returns to tboot for the
> second pass. If I turn both cores on, the
> bwr_sinit_20060922_release.bin SINIT will at least get back to tboot,
> and go through a second pass. So here's my question:
>
> Does SINIT require multiple cores to be enabled in order for it to
> work properly?

The only thing I can suggest here is that after a failure, you can
reboot and then read the LT.ERRORCODE register. The Sourceforge
download package for the SINIT module includes a table of failure and
progress codes that get stored in this register by SINIT as it runs.
By relating the progress/error code to the information in the file
from the SINIT download package it might shed light on where things
are going wrong. See also Table 23 in Appendix B of the Arch. spec,
which shows error codes in case it does not get to the point of
running the SINIT module.

Sorry I cannot be more help, this technology is very new to me too. I
hope to have more time over the holidays to get my experiments going -
just got my machine (HP dc7800) last week -

Hal Finney

[tboot-devel] SINIT question

[Emil M. <me...@os...>]

I have a quick question regarding the SINIT module.

I am currently creating a proof-of-concept of a VMM which can be
securely late-launched multiple times. The VMM itself is very similar
in design to Intel's LVMM, and I am in the process of getting it to be
launched through tboot, but am having a few problems with SINIT
executing properly.

I have the "Intel Desktop Board DQ965CO" which i believe is in the
ICH8 family, and with the board came the following SINIT module:
filename: bwr_sinit_20060922_release.bin
sha1sum: 8ad582e50be40df7da9c1b8db6ed77499e920613

Also I have downloaded the SINIT offered from the tboot package:
filename: BRLK_SINIT_20070910_release.BIN
sha1sum: 46f4e1c199c2983e8a8a115cd90c88353e7b08dc

My questions are:

1. Should I be able to use either of the SINIT modules for my
hardware, or are they specific to a certain chipset?

1b. If they are chipset specific, where can I get the latest version
of SINIT for my particular chipset?

2. In order to make the proof-of-concept easier to develop and debug,
I disabled one of the cores for the time being. However, with a core
disabled, neither of the SINIT modules listed above would execute
properly. (actually, the one offered on the tboot website doesn't boot
at all under any circumstance) What happens is that tboot goes through
its first pass, confirms that the SINIT is correct, and then attempts
to execute GETSEC[SENTER]. However, it never returns to tboot for the
second pass. If I turn both cores on, the
bwr_sinit_20060922_release.bin SINIT will at least get back to tboot,
and go through a second pass. So here's my question:

Does SINIT require multiple cores to be enabled in order for it to
work properly?

Thanks for all the questions you have answered on this mailing list.
Everything I have seen so far has been very interesting and
educational.

Emil Meng
University of Tsukuba
MS Computer Science

Re: [tboot-devel] SINIT AC Module now available

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

Hi Joe -

I am interested in the cryptography being used with regard to the
SINIT module and I wonder if you could answer some questions?

One thing I've been curious about is how (and why) the SINIT module is
signed. I did an experiment to look at how the signature is computed
in the sinit module header. I took the sig value and raised it to the
17th power modulo the key modulus, and got this result:

0x1ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff004ded501d729278ff815ec7a9cdf0267f686012b2

That's good, or at least pretty good, it has the PKCS-1 v1.5 padding
followed by a byte of zeros, then the 20-byte payload which should be
the hash of the data. Now actually you should have the payload
preceded by some ASN.1 to represent the SHA-1 algorithm, but this is
pretty close to standard.

Then I took the file and snipped out the key, sig and scratch area,
and ran sha1sum over it, and got:

b21260687f26f0cda9c75e81ff7892721d50ed4d

Again, that's pretty good, it matches the PKCS-1 payload, except...
it's byte-reversed. So that's kind of weird. It's not a problem per se
but it's nonstandard, and it is interesting that the chipset or
microcode or whatever does this reversal.

So some of my questions are, does the CPU/chipset actually check the
signature on the SINIT module? And then, what signing key does it use?
Is there a signing key built into the chipset that it expects to see,
or does it just use the signing key that it finds in the SINIT header?
The latter would be a little questionable cryptographically, since
anyone could create a key and sign any AC module, putting their own
key and signature into the header. I guess it depends on what Intel's
purpose is in having this signature at all.

Related to this, is there any information on exactly what gets hashed
into PCR17 when this SINIT module loads? Is it exactly the same
sequence of bytes that the signature covers? So what gets extended
into PCR17 would be the hash I listed above? In that case, according
to my calculations starting PCR17 with zeros and extending the hash
value above would lead to this as the content of PCR17 after the SINIT
module loads:

3ee34dd343b5b94704a5e6844d4f85814bbe6c2d

I wonder if you could report what is in PCR17 after a tboot launch
using this SINIT module?

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?

Sorry about all the questions, but of course this information is
necessary in order to relate the contents of the PCR registers to the
code that was loaded, which is of course one of the main points of
this technology! So I hope you or Intel will be able to provide some
information about this soon. Thanks very much -

Hal Finney

[tboot-devel] SINIT AC Module now available

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

The latest (only) SINIT AC Module, for the ICH9 (aka Bearlake) chipset,
is now available for download from the Trusted Boot downloads page.

Joe

Re: [tboot-devel] Additional Questions

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

On Tuesday, December 04, 2007 7:45 PM, Atsushi SAKAI wrote:
> Hi, Joe
>=20
>   Thank you for various answers.
> I still have several questions.
> I would be appreciate if you answer the question.
>=20
> 1)Is SHA256 planned to use?
>   (since definition exists in code)

It is possible that we will support SHA-256 in the future, and since the
hash size is larger, we wanted to make sure that we would not have to
change the data layout if we did.

> Following questions are from Intel TXT Spec(Aug 2007)
>=20
> 2)What is GV3 MSRs?(p.69)

These are the Intel(R) SpeedStep MSRs that govern frequency/voltage
settings.

> 3)In Intel TXT Specification(August 2007)
>   Appendix D.1.3 - D.1.5
>   seems old(since same Data Struct is written in
>    Appendix C)

The contents of the data structures are different.  Appendix D is for
the TEP only and so these are legacy data structure versions.

> 4)In Intel TXT Specification(August 2007)
>   p.59 (see Appendix "0")
>   should be Appendix "C"

Good catch--we'll fix it in the next rev.

>> From Intel 64 and IA-32 Software Developers Manual.
> 5) Where is the following manual?
> Trusted Execution Technology Measured Launched Environment Programming

That is the title for the next revision of the TXT Preliminary
Architecture Specification.  We should have it available early next
year.

>=20
> Thanks
> Atsushi SAKAI
>=20
>=20
>=20
>=20
>
------------------------------------------------------------------------
-
> SF.Net email is sponsored by: The Future of Linux Business White Paper
> from Novell.  From the desktop to the data center, Linux is going
> mainstream.  Let it simplify your IT future.
> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
> _______________________________________________
> tboot-devel mailing list
> tbo...@li...
> https://lists.sourceforge.net/lists/listinfo/tboot-devel

[tboot-devel] Additional Questions

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

Hi, Joe

  Thank you for various answers.
I still have several questions.
I would be appreciate if you answer the question.

1)Is SHA256 planned to use?
  (since definition exists in code)

Following questions are from Intel TXT Spec(Aug 2007)

2)What is GV3 MSRs?(p.69)

3)In Intel TXT Specification(August 2007)
  Appendix D.1.3 - D.1.5 
  seems old(since same Data Struct is written in 
   Appendix C)

4)In Intel TXT Specification(August 2007)
  p.59 (see Appendix "0") 
  should be Appendix "C"

>From Intel 64 and IA-32 Software Developers Manual.
5) Where is the following manual?
Trusted Execution Technology Measured Launched Environment Programming  

Thanks
Atsushi SAKAI

Re: [tboot-devel] SDV3/TEP mean what?

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

On Monday, December 03, 2007 8:12 PM, Atsushi SAKAI wrote:
> Hi, Joe
>=20
> Thank you for answering my question.
>=20
> Anyway, In code, SDP3/TEP and SDP3 exists on
> tboot/common/tpm.c
> tboot/include/config.h
> tboot/include/txt/heap.h
>=20
> Are these different abbreviation?

Sorry about the confusion--Intel "renamed" "SDV" to "SDP" (Software
Deevelopment Platform) as part of our "platformization" focus last year.
They are the same thing and I'll try and remove all of the "SDV"
occurrences.

Joe

>=20
> Thanks
> Atsushi SAKAI
>=20
>=20
>=20
> "Cihula, Joseph" <jos...@in...> wrote:
>=20
>>> Atsushi SAKAI <> scribbled on 2007-11-30 16:43 PM:
>>>=20
>>>> Hi,
>>>>=20
>>>>  I am looking around the tboot-20071128 package.
>>>> Then I raised one question.
>>>>  What does SDV3/TEP mean?
>>>> I understand TEP  as Technology Enabling Platform
>>>> But I do not know the SDV3 mean?
>>>> Is there any explaining pointer exists?
>>=20
>> An "SDV3" is a type of Software Development Vehicle, i.e.
>> platform/system, that Intel makes available to certain partners under
an
>> NDA in order to enable ecosystem development for pre-release
>> technologies.  This particular SDV is very similar in functionality
to the
>> TEP.=20
>>=20
>> Joe
>>=20
>>
------------------------------------------------------------------------
-
>> SF.Net email is sponsored by: The Future of Linux Business White
Paper
>> from Novell.  From the desktop to the data center, Linux is going
>> mainstream.  Let it simplify your IT future.
>> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
>> _______________________________________________
>> tboot-devel mailing list
>> tbo...@li...
>> https://lists.sourceforge.net/lists/listinfo/tboot-devel

Re: [tboot-devel] SDV3/TEP mean what?

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

Hi, Joe

Thank you for answering my question.

Anyway, In code, SDP3/TEP and SDP3 exists on 
tboot/common/tpm.c
tboot/include/config.h
tboot/include/txt/heap.h

Are these different abbreviation?

Thanks
Atsushi SAKAI



"Cihula, Joseph" <jos...@in...> wrote:

> > Atsushi SAKAI <> scribbled on 2007-11-30 16:43 PM:
> > 
> >> Hi,
> >> 
> >>  I am looking around the tboot-20071128 package.
> >> Then I raised one question.
> >>  What does SDV3/TEP mean?
> >> I understand TEP  as Technology Enabling Platform
> >> But I do not know the SDV3 mean?
> >> Is there any explaining pointer exists?
> 
> An "SDV3" is a type of Software Development Vehicle, i.e.
> platform/system, that Intel makes available to certain partners under an
> NDA in order to enable ecosystem development for pre-release
> technologies.  This particular SDV is very similar in functionality to
> the TEP.
> 
> Joe
> 
> -------------------------------------------------------------------------
> SF.Net email is sponsored by: The Future of Linux Business White Paper
> from Novell.  From the desktop to the data center, Linux is going
> mainstream.  Let it simplify your IT future.
> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
> _______________________________________________
> tboot-devel mailing list
> tbo...@li...
> https://lists.sourceforge.net/lists/listinfo/tboot-devel

[tboot-devel] [patch][doc] typo

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

typo fix

Thanks
Atsushi SAKAI

Re: [tboot-devel] SDV3/TEP mean what?

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

> Atsushi SAKAI <> scribbled on 2007-11-30 16:43 PM:
>=20
>> Hi,
>>=20
>>  I am looking around the tboot-20071128 package.
>> Then I raised one question.
>>  What does SDV3/TEP mean?
>> I understand TEP  as Technology Enabling Platform
>> But I do not know the SDV3 mean?
>> Is there any explaining pointer exists?

An "SDV3" is a type of Software Development Vehicle, i.e.
platform/system, that Intel makes available to certain partners under an
NDA in order to enable ecosystem development for pre-release
technologies.  This particular SDV is very similar in functionality to
the TEP.

Joe

[tboot-devel] SDV3/TEP mean what?

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

Hi, 

 I am looking around the tboot-20071128 package.
Then I raised one question.
 What does SDV3/TEP mean?
I understand TEP  as Technology Enabling Platform
But I do not know the SDV3 mean?
Is there any explaining pointer exists?

Thanks
Atsushi SAKAI

[tboot-devel] this is only a test, pls ignore it.

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

-- Jimmy