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

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

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

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

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

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


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

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

Hal Finney