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.