tboot-devel

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

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

[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

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

[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