From: Seiji M. <sei...@gm...> - 2008-04-17 11:30:59
|
Hi Folks, Is there any way to validate the PCR[17] and PCR18] values? In case of Static-RTM, we can validate the PCR values by using the BIOS eventlog stored at ACPI table. But for Dynamic-RTM we don't have such eventlog. I just tried different tpm_extend combinations from digests in the tboot's console message. but I can't find the right combination to produce the PCR17,18 values. I'm using Fedora8 and Xen-3.2 on DQ35JO board (BIOS v865) and my grub.conf is title Fedora (2.6.21.7-2.fc8xen) XEN 3.2 w/ TBOOT root (hd0,4) kernel /boot/tboot.gz module /boot/xen.gz-3.2 vtd=1 com1=115200,8n1 module /boot/vmlinuz-2.6.21.7-2.fc8xen ro root=LABEL=/1 module /boot/initrd-2.6.21.7-2.fc8xen.img module /boot/BRLK_SINIT_20070910_release.BIN Actually, the xen and kernel digest I found in the console massage were correct (same as the sha1 digest of gunziped file). But, the digest of SINIT code was somehow different. TBOOT: sinit_hash= b2 12 60 68 7f 26 f0 cd a9 c7 5e 81 ff 78 92 72 1d 50 ed 4d # sha1sum /boot/BRLK_SINIT_20070910_release.BIN 46f4e1c199c2983e8a8a115cd90c88353e7b08dc Thanks, -- Seiji |
From: Hal F. <hal...@gm...> - 2008-04-17 16:46:28
|
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 |
From: Cihula, J. <jos...@in...> - 2008-04-17 17:04:03
|
Here is the text from the draft of the updated TXT spec (empirically verified on my system): 1.9 PCR Usage As part of the measured launch, Intel TXT will extend measurements of the elements and configuration values of the dynamic root of trust into certain TPM PCRs. The constituent values of these measurements (indicated below) are provided in the SinitMleData structure described in Appendix C.4. While the MLE may choose to extend additional values into these PCRs, the values described below are those present immediately after the MLE receives control following the GETSEC[SENTER] instruction. 1.9.1 PCR 17 PCR 17 is initialized using the TPM_HASH_START/TPM_HASH_END sequence. The HASH_DATA provided in this sequence is the concatenation of the SHA-1 hash of the SINIT ACM that was used in the launch process and the 4 byte value of the SENTER parameters (in EDX and also in SinitMleData.EdxSenterFlags). As part of this sequence, PCRs 17-23 are reset to 0. The hash of SINIT is also stored in the SinitMleData.SinitHash field. PCR 17 is then extended with the SHA-1 hash of the following items concatenated in this order: SHA-1 hash of SCLEAN ACM - SinitMleData.BiosAcmID (20 bytes) STM opt-in indicator - SinitMleData.MsegValid (8 bytes) SHA-1 hash of the STM (or all 0s if opt-out) - SinitMleData.StmHash (20 bytes) LCP Control Field of used policy (PD or PO) - SinitMleData.PolicyControl (4 bytes) SHA-1 hash of used policy - SinitMleData.LcpPolicyHash (20 bytes) Thus, PCR 17's final value will be: Extend ( SHA-1( SinitMleData.SinitHash | SinitMleData.EdxSenterFlags ) ) Extend ( SHA-1 ( SinitMleData.BiosAcm.ID | SinitMleData.MsegValid | SinitMleData.StmHash | SinitMleData.PolicyControl | SinitMleData.LcpPolicyHash ) ) Where the Extend() operation is a SHA-1 hash of the previous value in the PCR concatenated with the value being extended (the previous value is 20 bytes of 0s in the case of the first extend to a PCR). 1.9.2 PCR 18 PCR 18 will be extended with the SHA-1 hash of the MLE, as reported in the SinitMleData.MleHash field. Thus, PCR 18's final value will be: Extend ( SinitMleData.MleHash ) Joe On Thursday, April 17, 2008 9:46 AM, Hal Finney wrote: > 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 > > ------------------------------------------------------------------------ - > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/j avaone > _______________________________________________ > tboot-devel mailing list > tbo...@li... > https://lists.sourceforge.net/lists/listinfo/tboot-devel |
From: Seiji M. <sei...@gm...> - 2008-04-18 03:30:07
|
Hi Hal, Joe. Thank you for your advices. That is a big help. 2008/4/18, Hal Finney <hal...@gm...>: > Seiji, have you tried reading PCR 17 and PCR 18? What values do you get? Yes. here is, # cat /sys/class/misc/tpm0/device/pcrs <snip> PCR-16: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 PCR-17: C0 E5 23 76 84 CD 97 4F DF 6E CD 4A 27 17 EA 63 B0 99 B2 82 PCR-18: 55 50 38 7D 03 F1 EE FA 45 49 65 5A 70 27 85 B4 14 4B C5 2E PCR-19: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 PCR-20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 PCR-21: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 PCR-22: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 PCR-23: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 and boot message is as follows <snip> TBOOT: sinit_mle_data (@7d4201a4, 260): TBOOT: version=5 TBOOT: bios_acm_id= 80 00 00 00 20 07 09 10 ff ff ff ff ff ff ff ff ff ff ff ff TBOOT: edx_senter_flags=0 TBOOT: mseg_valid=0 TBOOT: sinit_hash= b2 12 60 68 7f 26 f0 cd a9 c7 5e 81 ff 78 92 72 1d 50 ed 4d TBOOT: mle_hash= df 7b ac e3 5f a2 3d 23 d4 fe 1a 4a 25 8b 4e 4e b0 c2 64 a4 TBOOT: stm_hash= 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 TBOOT: lcp_policy_hash= df 7b ac e3 5f a2 3d 23 d4 fe 1a 4a 25 8b 4e 4e b0 c2 64 a4 TBOOT: lcp_policy_control=0 <snip> 1st step, I'd like to validate the PCRs by using the TBOOT message. I verified the PCR18 by just extend the mle_hash value. good. But I have not been able to validate the PCR17... 2nd step, will create hash values in TBOOT massage from SINIT file. Then we will be able to predict the PCRs extended by the TXT.:-) Thanks, -- Seiji |
From: Seiji M. <sei...@gm...> - 2008-04-18 07:16:47
|
2008/4/18, Seiji Munetoh <sei...@gm...>: > 1st step, I'd like to validate the PCRs by using the TBOOT message. > I verified the PCR18 by just extend the mle_hash value. good. > But I have not been able to validate the PCR17... Sorry, my calc was wrong. Now, I have confirmed both PCR17 and PCR18 values. :-) Thanks!!! -- Seiji |
From: Jun K. <jun...@gm...> - 2008-04-25 14:47:17
|
On 4/17/08, 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. Do you know if there is any good reason why tboot doesn't log events into eventlog? thanks, J |
From: Cihula, J. <jos...@in...> - 2008-04-25 19:40:18
|
On Friday, April 25, 2008 7:47 AM, Jun Koi wrote: > On 4/17/08, 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. > > Do you know if there is any good reason why tboot doesn't log events > into eventlog? Did you mean why tboot doesn't copy the extend information into the BIOS event log or why TXT itself doesn't put them there? For the former, it is a combination of lack of time, issues with the eventlog, and motivation. Regarding the eventlog, the current TCG specification does not provide for BIOS to indicate where the log data ends. There is a soon-to-be-released update for the spec that will specify that the end space be filled with ff's, but that will require updated BIOSes. Regarding motivation, it wasn't clear how useful or important it would be. The values for PCR 17 and 18 are available in the SinitMleData struct in the TXT heap. So MLEs can access it and expose it to whatever SW needs it. For TXT not doing it, the reasons are very similar. In addition, we didn't want to tie the launch process to BIOS and its configuration. Joe |
From: Jun K. <jun...@gm...> - 2008-05-01 10:28:28
|
On Sat, Apr 26, 2008 at 4:40 AM, Cihula, Joseph <jos...@in...> wrote: > > On Friday, April 25, 2008 7:47 AM, Jun Koi wrote: > > On 4/17/08, 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. > > > > Do you know if there is any good reason why tboot doesn't log events > > into eventlog? > > Did you mean why tboot doesn't copy the extend information into the BIOS > event log or why TXT itself doesn't put them there? > > For the former, it is a combination of lack of time, issues with the > eventlog, and motivation. Regarding the eventlog, the current TCG > specification does not provide for BIOS to indicate where the log data > ends. There is a soon-to-be-released update for the spec that will > specify that the end space be filled with ff's, but that will require > updated BIOSes. Regarding motivation, it wasn't clear how useful or > important it would be. > > The values for PCR 17 and 18 are available in the SinitMleData struct in > the TXT heap. So MLEs can access it and expose it to whatever SW needs > it. > > For TXT not doing it, the reasons are very similar. In addition, we > didn't want to tie the launch process to BIOS and its configuration. > Thanks Joseph for the informative answer. Jun |
From: Jun K. <jun...@gm...> - 2008-05-16 07:55:04
|
Hi Joseph, >>> 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. >> >> Do you know if there is any good reason why tboot doesn't log events >> into eventlog? > > Did you mean why tboot doesn't copy the extend information into the BIOS > event log or why TXT itself doesn't put them there? > > For the former, it is a combination of lack of time, issues with the > eventlog, and motivation. Regarding the eventlog, the current TCG > specification does not provide for BIOS to indicate where the log data > ends. There is a soon-to-be-released update for the spec that will > specify that the end space be filled with ff's, but that will require > updated BIOSes. Regarding motivation, it wasn't clear how useful or > important it would be. > > The values for PCR 17 and 18 are available in the SinitMleData struct in > the TXT heap. So MLEs can access it and expose it to whatever SW needs > it. > > For TXT not doing it, the reasons are very similar. In addition, we > didn't want to tie the launch process to BIOS and its configuration. > I think again about the above comment: we dont want to tie with BIOS, thus we must not call BIOS functions to measure/extend configuration data. Therefore, it is a good idea for the next code launched by tboot (like Xen or a particular OS) should not use BIOS at all, right? If so, I suppose that all the Xen code now already removed all the calls to BIOS??? Many thanks, Jun |
From: Jun K. <jun...@gm...> - 2008-05-23 06:49:24
|
On 5/16/08, Jun Koi <jun...@gm...> wrote: > Hi Joseph, > > > >>> 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. > >> > >> Do you know if there is any good reason why tboot doesn't log events > >> into eventlog? > > > > Did you mean why tboot doesn't copy the extend information into the BIOS > > event log or why TXT itself doesn't put them there? > > > > For the former, it is a combination of lack of time, issues with the > > eventlog, and motivation. Regarding the eventlog, the current TCG > > specification does not provide for BIOS to indicate where the log data > > ends. There is a soon-to-be-released update for the spec that will > > specify that the end space be filled with ff's, but that will require > > updated BIOSes. Regarding motivation, it wasn't clear how useful or > > important it would be. > > > > The values for PCR 17 and 18 are available in the SinitMleData struct in > > the TXT heap. So MLEs can access it and expose it to whatever SW needs > > it. > > > > For TXT not doing it, the reasons are very similar. In addition, we > > didn't want to tie the launch process to BIOS and its configuration. > > > > > I think again about the above comment: we dont want to tie with BIOS, > thus we must not call BIOS functions to measure/extend configuration > data. Therefore, it is a good idea for the next code launched by tboot > (like Xen or a particular OS) should not use BIOS at all, right? > > If so, I suppose that all the Xen code now already removed all the > calls to BIOS??? > So basically the question is: should we execute other code outside our "trusted code"? In this example, BIOS code is not trusted. Or we should avoid that as much as we can? Thanks, Jun |
From: Hal F. <hal...@gm...> - 2008-05-25 22:33:40
|
Hello Jun - On Thu, May 22, 2008 at 11:49 PM, Jun Koi <jun...@gm...> wrote: > So basically the question is: should we execute other code outside our > "trusted code"? In this example, BIOS code is not trusted. Or we > should avoid that as much as we can? That certainly makes sense to me. There are really two points here. The first is that we don't trust the BIOS because we don't know what is in it. The TXT launch does not measure the BIOS and so the TXT PCRs do not depend on BIOS contents. Any call we make to BIOS would run code that could not be verified. The second point is that if we did originally do a measured boot, so that PCR's 0-7 contain information about BIOS and other aspects of the computer configuration, then if we made a call to BIOS, in principle we could trust that. The verifier could check that the BIOS configuration was as expected and if the BIOS was known to be trusted by that verifier, the call would be OK. But there are still problems. One problem is the size of the Trusted Computer Base (TCB). Including the whole BIOS into the TCB makes it larger (although I don't know how the BIOS size will compare with Xen). Also, BIOSes often do not have much transparency so it may be hard to get hold of the source code and know what the BIOS is doing. Also, there are many different brands and varieties of BIOS so it would be hard to trust very many of them. Another point is that some BIOSes have not done measured boot properly and it may be possible to reflash the BIOS to lie about the measured boot. Part of the goal of TXT technology is to reduce the size of the TCB and avoid dependence on measured boot. Avoiding calls into the BIOS would be a good idea for any TXT Measured Launch Environment (MLE) including Xen. However I don't know whether Xen has done as you suggest, and avoids BIOS calls when in trusted mode. Hal Finney |
From: Cihula, J. <jos...@in...> - 2008-05-27 18:22:41
|
Hal's answer is spot-on. One of TXT's goals is to remove BIOS from the trust chain, and so we would prefer not to have to trust it, which means not calling into it from the TCB. TXT does, however, support verification of BIOS (of any of the static PCRs) as part of its launch control policy. The TXT support in Xen disables the two BIOS calls (for the e820 table and video initialization) that Xen would otherwise make. This has worked fine for all of the TXT systems that I am aware of and is likely due to TXT only being available on newer systems (with fewer issues in these areas). Joe -----Original Message----- From: Hal Finney [mailto:hal...@gm...] Sent: Sunday, May 25, 2008 3:34 PM To: Jun Koi Cc: Cihula, Joseph; tbo...@li... Subject: Re: [tboot-devel] How to validate the PCR measured by TXT? Hello Jun - On Thu, May 22, 2008 at 11:49 PM, Jun Koi <jun...@gm...> wrote: > So basically the question is: should we execute other code outside our > "trusted code"? In this example, BIOS code is not trusted. Or we > should avoid that as much as we can? That certainly makes sense to me. There are really two points here. The first is that we don't trust the BIOS because we don't know what is in it. The TXT launch does not measure the BIOS and so the TXT PCRs do not depend on BIOS contents. Any call we make to BIOS would run code that could not be verified. The second point is that if we did originally do a measured boot, so that PCR's 0-7 contain information about BIOS and other aspects of the computer configuration, then if we made a call to BIOS, in principle we could trust that. The verifier could check that the BIOS configuration was as expected and if the BIOS was known to be trusted by that verifier, the call would be OK. But there are still problems. One problem is the size of the Trusted Computer Base (TCB). Including the whole BIOS into the TCB makes it larger (although I don't know how the BIOS size will compare with Xen). Also, BIOSes often do not have much transparency so it may be hard to get hold of the source code and know what the BIOS is doing. Also, there are many different brands and varieties of BIOS so it would be hard to trust very many of them. Another point is that some BIOSes have not done measured boot properly and it may be possible to reflash the BIOS to lie about the measured boot. Part of the goal of TXT technology is to reduce the size of the TCB and avoid dependence on measured boot. Avoiding calls into the BIOS would be a good idea for any TXT Measured Launch Environment (MLE) including Xen. However I don't know whether Xen has done as you suggest, and avoids BIOS calls when in trusted mode. Hal Finney |
From: Martin T. <ma...@th...> - 2008-06-02 18:41:13
|
Ah, so that's why you added an alternative memory map in TXT ;-) Clearly, when TXT goes to the extent of not even trusting the BIOS-supplied memory map, one should be careful calling any BIOS code. However, I'm wondering if it would be possible to validate the BIOS after the MLE launch by simply hashing the code involved without using any PCR's etc.? After all, the code in the MLE would more or less have full control of the computer and should thus be able to read the BIOS code and compare it against a (trusted) list. The danger is that the MLE would have to hash all code that is included in the code paths of the functions it will call. Someone told me, but I don't know if it's true, that BIOS'es these days are so big that not all is present in the address space at any given time (due to the limited numer of addresses in real mode). Instead it does some sort of bank switching. If this is true it will require knowledge of the bank-switching mechanism in order to do a full hash of the BIOS and even then the MLE would have to be able to guarentee that no one can tamper with the mechanism during execution of the BIOS functions etc. Best regards, Martin Thiim On 5/27/08, Cihula, Joseph <jos...@in...> wrote: > Hal's answer is spot-on. One of TXT's goals is to remove BIOS from the > trust chain, and so we would prefer not to have to trust it, which means > not calling into it from the TCB. TXT does, however, support > verification of BIOS (of any of the static PCRs) as part of its launch > control policy. > > The TXT support in Xen disables the two BIOS calls (for the e820 table > and video initialization) that Xen would otherwise make. This has > worked fine for all of the TXT systems that I am aware of and is likely > due to TXT only being available on newer systems (with fewer issues in > these areas). > > Joe > > -----Original Message----- > From: Hal Finney [mailto:hal...@gm...] > Sent: Sunday, May 25, 2008 3:34 PM > To: Jun Koi > Cc: Cihula, Joseph; tbo...@li... > Subject: Re: [tboot-devel] How to validate the PCR measured by TXT? > > Hello Jun - > > On Thu, May 22, 2008 at 11:49 PM, Jun Koi <jun...@gm...> wrote: > > So basically the question is: should we execute other code outside our > > "trusted code"? In this example, BIOS code is not trusted. Or we > > should avoid that as much as we can? > > That certainly makes sense to me. There are really two points here. > The first is that we don't trust the BIOS because we don't know what > is in it. The TXT launch does not measure the BIOS and so the TXT PCRs > do not depend on BIOS contents. Any call we make to BIOS would run > code that could not be verified. > > The second point is that if we did originally do a measured boot, so > that PCR's 0-7 contain information about BIOS and other aspects of the > computer configuration, then if we made a call to BIOS, in principle > we could trust that. The verifier could check that the BIOS > configuration was as expected and if the BIOS was known to be trusted > by that verifier, the call would be OK. But there are still problems. > > One problem is the size of the Trusted Computer Base (TCB). Including > the whole BIOS into the TCB makes it larger (although I don't know how > the BIOS size will compare with Xen). Also, BIOSes often do not have > much transparency so it may be hard to get hold of the source code and > know what the BIOS is doing. Also, there are many different brands and > varieties of BIOS so it would be hard to trust very many of them. > Another point is that some BIOSes have not done measured boot properly > and it may be possible to reflash the BIOS to lie about the measured > boot. > > Part of the goal of TXT technology is to reduce the size of the TCB > and avoid dependence on measured boot. Avoiding calls into the BIOS > would be a good idea for any TXT Measured Launch Environment (MLE) > including Xen. However I don't know whether Xen has done as you > suggest, and avoids BIOS calls when in trusted mode. > > Hal Finney > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > tboot-devel mailing list > tbo...@li... > https://lists.sourceforge.net/lists/listinfo/tboot-devel > |
From: Cihula, J. <jos...@in...> - 2008-06-03 20:32:14
|
There are a lot of challenges to making a meaningful and reproducible measurement of executing or executed code. Since BIOS will have already executed quite a bit of code, the contents of its persistent data are likely to depend on the code that was executed post-boot (i.e. MBR, bootloader, etc.) and perhaps even pluggable hardware (e.g. USB). Thus, if any of this code changes how it uses BIOS, the BIOS's measurement may change as well. Additionally, the best you could do with this type of measurement would be to compare it to a "golden" value taken with the same boot and hardware conditions on a known-good system. For Xen, it is much easier to simply avoid calling back into BIOS. Linux, however, has many more BIOS calls and it would be more of a challenge to remove those. Joe From: Martin Thiim [mailto:ma...@th...] Sent: Monday, June 02, 2008 11:41 AM To: Cihula, Joseph Cc: Hal Finney; Jun Koi; tbo...@li... Subject: Re: [tboot-devel] How to validate the PCR measured by TXT? Ah, so that's why you added an alternative memory map in TXT ;-) Clearly, when TXT goes to the extent of not even trusting the BIOS-supplied memory map, one should be careful calling any BIOS code. However, I'm wondering if it would be possible to validate the BIOS after the MLE launch by simply hashing the code involved without using any PCR's etc.? After all, the code in the MLE would more or less have full control of the computer and should thus be able to read the BIOS code and compare it against a (trusted) list. The danger is that the MLE would have to hash all code that is included in the code paths of the functions it will call. Someone told me, but I don't know if it's true, that BIOS'es these days are so big that not all is present in the address space at any given time (due to the limited numer of addresses in real mode). Instead it does some sort of bank switching. If this is true it will require knowledge of the bank-switching mechanism in order to do a full hash of the BIOS and even then the MLE would have to be able to guarentee that no one can tamper with the mechanism during execution of the BIOS functions etc. Best regards, Martin Thiim On 5/27/08, Cihula, Joseph <jos...@in...> wrote: Hal's answer is spot-on. One of TXT's goals is to remove BIOS from the trust chain, and so we would prefer not to have to trust it, which means not calling into it from the TCB. TXT does, however, support verification of BIOS (of any of the static PCRs) as part of its launch control policy. The TXT support in Xen disables the two BIOS calls (for the e820 table and video initialization) that Xen would otherwise make. This has worked fine for all of the TXT systems that I am aware of and is likely due to TXT only being available on newer systems (with fewer issues in these areas). Joe -----Original Message----- From: Hal Finney [mailto:hal...@gm...] Sent: Sunday, May 25, 2008 3:34 PM To: Jun Koi Cc: Cihula, Joseph; tbo...@li... Subject: Re: [tboot-devel] How to validate the PCR measured by TXT? Hello Jun - On Thu, May 22, 2008 at 11:49 PM, Jun Koi <jun...@gm...> wrote: > So basically the question is: should we execute other code outside our > "trusted code"? In this example, BIOS code is not trusted. Or we > should avoid that as much as we can? That certainly makes sense to me. There are really two points here. The first is that we don't trust the BIOS because we don't know what is in it. The TXT launch does not measure the BIOS and so the TXT PCRs do not depend on BIOS contents. Any call we make to BIOS would run code that could not be verified. The second point is that if we did originally do a measured boot, so that PCR's 0-7 contain information about BIOS and other aspects of the computer configuration, then if we made a call to BIOS, in principle we could trust that. The verifier could check that the BIOS configuration was as expected and if the BIOS was known to be trusted by that verifier, the call would be OK. But there are still problems. One problem is the size of the Trusted Computer Base (TCB). Including the whole BIOS into the TCB makes it larger (although I don't know how the BIOS size will compare with Xen). Also, BIOSes often do not have much transparency so it may be hard to get hold of the source code and know what the BIOS is doing. Also, there are many different brands and varieties of BIOS so it would be hard to trust very many of them. Another point is that some BIOSes have not done measured boot properly and it may be possible to reflash the BIOS to lie about the measured boot. Part of the goal of TXT technology is to reduce the size of the TCB and avoid dependence on measured boot. Avoiding calls into the BIOS would be a good idea for any TXT Measured Launch Environment (MLE) including Xen. However I don't know whether Xen has done as you suggest, and avoids BIOS calls when in trusted mode. Hal Finney ------------------------------------------------------------------------ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ tboot-devel mailing list tbo...@li... https://lists.sourceforge.net/lists/listinfo/tboot-devel |
From: Jun K. <jun...@gm...> - 2008-06-09 07:54:59
|
On Wed, Jun 4, 2008 at 5:31 AM, Cihula, Joseph <jos...@in...> wrote: > There are a lot of challenges to making a meaningful and reproducible > measurement of executing or executed code. Since BIOS will have already > executed quite a bit of code, the contents of its persistent data are likely > to depend on the code that was executed post-boot (i.e. MBR, bootloader, > etc.) and perhaps even pluggable hardware (e.g. USB). Thus, if any of this > code changes how it uses BIOS, the BIOS's measurement may change as well. > Additionally, the best you could do with this type of measurement would be > to compare it to a "golden" value taken with the same boot and hardware > conditions on a known-good system. > > > > For Xen, it is much easier to simply avoid calling back into BIOS. Linux, > however, has many more BIOS calls and it would be more of a challenge to > remove those. > If so, our current solution doesnt look very good to me. We have tboot boots first, then Xen and Dom0 are loaded as multiboot modules. However, Dom0 (which is Linux) executes non-measured code, that is BIOS interrupt handlers. Is that bad? Any way to fix this problem??? Thanks, Jun > From: Martin Thiim [mailto:ma...@th...] > Sent: Monday, June 02, 2008 11:41 AM > To: Cihula, Joseph > Cc: Hal Finney; Jun Koi; tbo...@li... > Subject: Re: [tboot-devel] How to validate the PCR measured by TXT? > > > > Ah, so that's why you added an alternative memory map in TXT ;-) > > > > Clearly, when TXT goes to the extent of not even trusting the BIOS-supplied > memory map, one should be careful calling any BIOS code. However, I'm > wondering if it would be possible to validate the BIOS after the MLE > launch by simply hashing the code involved without using any PCR's etc.? > After all, the code in the MLE would more or less have full control of the > computer and should thus be able to read the BIOS code and compare it > against a (trusted) list. The danger is that the MLE would have to hash all > code that is included in the code paths of the functions it will call. > Someone told me, but I don't know if it's true, that BIOS'es these days are > so big that not all is present in the address space at any given time (due > to the limited numer of addresses in real mode). Instead it does some sort > of bank switching. If this is true it will require knowledge of the > bank-switching mechanism in order to do a full hash of the BIOS and even > then the MLE would have to be able to guarentee that no one can tamper with > the mechanism during execution of the BIOS functions etc. > > > > Best regards, > > > > Martin Thiim > > > > On 5/27/08, Cihula, Joseph <jos...@in...> wrote: > > Hal's answer is spot-on. One of TXT's goals is to remove BIOS from the > trust chain, and so we would prefer not to have to trust it, which means > not calling into it from the TCB. TXT does, however, support > verification of BIOS (of any of the static PCRs) as part of its launch > control policy. > > The TXT support in Xen disables the two BIOS calls (for the e820 table > and video initialization) that Xen would otherwise make. This has > worked fine for all of the TXT systems that I am aware of and is likely > due to TXT only being available on newer systems (with fewer issues in > these areas). > > Joe > > -----Original Message----- > From: Hal Finney [mailto:hal...@gm...] > Sent: Sunday, May 25, 2008 3:34 PM > To: Jun Koi > Cc: Cihula, Joseph; tbo...@li... > Subject: Re: [tboot-devel] How to validate the PCR measured by TXT? > > Hello Jun - > > On Thu, May 22, 2008 at 11:49 PM, Jun Koi <jun...@gm...> wrote: >> So basically the question is: should we execute other code outside our >> "trusted code"? In this example, BIOS code is not trusted. Or we >> should avoid that as much as we can? > > That certainly makes sense to me. There are really two points here. > The first is that we don't trust the BIOS because we don't know what > is in it. The TXT launch does not measure the BIOS and so the TXT PCRs > do not depend on BIOS contents. Any call we make to BIOS would run > code that could not be verified. > > The second point is that if we did originally do a measured boot, so > that PCR's 0-7 contain information about BIOS and other aspects of the > computer configuration, then if we made a call to BIOS, in principle > we could trust that. The verifier could check that the BIOS > configuration was as expected and if the BIOS was known to be trusted > by that verifier, the call would be OK. But there are still problems. > > One problem is the size of the Trusted Computer Base (TCB). Including > the whole BIOS into the TCB makes it larger (although I don't know how > the BIOS size will compare with Xen). Also, BIOSes often do not have > much transparency so it may be hard to get hold of the source code and > know what the BIOS is doing. Also, there are many different brands and > varieties of BIOS so it would be hard to trust very many of them. > Another point is that some BIOSes have not done measured boot properly > and it may be possible to reflash the BIOS to lie about the measured > boot. > > Part of the goal of TXT technology is to reduce the size of the TCB > and avoid dependence on measured boot. Avoiding calls into the BIOS > would be a good idea for any TXT Measured Launch Environment (MLE) > including Xen. However I don't know whether Xen has done as you > suggest, and avoids BIOS calls when in trusted mode. > > Hal Finney > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > tboot-devel mailing list > tbo...@li... > https://lists.sourceforge.net/lists/listinfo/tboot-devel > > |
From: Cihula, J. <jos...@in...> - 2008-06-09 20:58:38
|
> -----Original Message----- > From: Jun Koi [mailto:jun...@gm...] > Sent: Monday, June 09, 2008 12:55 AM > To: Cihula, Joseph > Cc: Martin Thiim; Hal Finney; tbo...@li... > Subject: Re: [tboot-devel] How to validate the PCR measured by TXT? > > On Wed, Jun 4, 2008 at 5:31 AM, Cihula, Joseph <jos...@in...> wrote: >> There are a lot of challenges to making a meaningful and reproducible >> measurement of executing or executed code. Since BIOS will have already >> executed quite a bit of code, the contents of its persistent data are likely >> to depend on the code that was executed post-boot (i.e. MBR, bootloader, >> etc.) and perhaps even pluggable hardware (e.g. USB). Thus, if any of this >> code changes how it uses BIOS, the BIOS's measurement may change as well. >> Additionally, the best you could do with this type of measurement would be >> to compare it to a "golden" value taken with the same boot and hardware >> conditions on a known-good system. >> >> >> >> For Xen, it is much easier to simply avoid calling back into BIOS. Linux, >> however, has many more BIOS calls and it would be more of a challenge to >> remove those. >> > > If so, our current solution doesnt look very good to me. We have tboot > boots first, then Xen and Dom0 are loaded as multiboot modules. > However, Dom0 (which is Linux) executes non-measured code, that is > BIOS interrupt handlers. > > Is that bad? Any way to fix this problem??? > > Thanks, > Jun First, dom0 is not part of the core TCB, since the hypervisor and tboot are isolated from it. Thus, even if it calls unmeasured code that can't affect the core TCB. That said, dom0 is part of the system TCB since it can affect all other VMs. So we do need to be concerned if we want a completely measured TCB. However, tboot's measurement of dom0 doesn't really measure dom0's TCB. This is because dom0 will continue to load modules, run root scripts, etc. from its persistent file system, and that isn't measured by tboot. So to complete the measurement of dom0, you need IMA or a ramfs-based dom0 or some similar way of making the entire TCB measurable. Once you have that, then you can look at whether dom0 invokes any unmeasured code. dom0 can't invoke real mode code, so it can't make most BIOS calls. And I don't believe it supports the BIOS32 protected mode interfaces (which would require Xen support). So I think the BIOS aspect of unmeasured code is covered for dom0. It can execute ACPI methods via the ACPI interpreter. If this is a concern, I suppose ACPI could be measured by some component of dom0. Joe >> From: Martin Thiim [mailto:ma...@th...] >> Sent: Monday, June 02, 2008 11:41 AM >> To: Cihula, Joseph >> Cc: Hal Finney; Jun Koi; tbo...@li... >> Subject: Re: [tboot-devel] How to validate the PCR measured by TXT? >> >> >> >> Ah, so that's why you added an alternative memory map in TXT ;-) >> >> >> >> Clearly, when TXT goes to the extent of not even trusting the BIOS-supplied >> memory map, one should be careful calling any BIOS code. However, I'm >> wondering if it would be possible to validate the BIOS after the MLE >> launch by simply hashing the code involved without using any PCR's etc.? >> After all, the code in the MLE would more or less have full control of the >> computer and should thus be able to read the BIOS code and compare it >> against a (trusted) list. The danger is that the MLE would have to hash all >> code that is included in the code paths of the functions it will call. >> Someone told me, but I don't know if it's true, that BIOS'es these days are >> so big that not all is present in the address space at any given time (due >> to the limited numer of addresses in real mode). Instead it does some sort >> of bank switching. If this is true it will require knowledge of the >> bank-switching mechanism in order to do a full hash of the BIOS and even >> then the MLE would have to be able to guarentee that no one can tamper with >> the mechanism during execution of the BIOS functions etc. >> >> >> >> Best regards, >> >> >> >> Martin Thiim >> >> >> >> On 5/27/08, Cihula, Joseph <jos...@in...> wrote: >> >> Hal's answer is spot-on. One of TXT's goals is to remove BIOS from the >> trust chain, and so we would prefer not to have to trust it, which means >> not calling into it from the TCB. TXT does, however, support >> verification of BIOS (of any of the static PCRs) as part of its launch >> control policy. >> >> The TXT support in Xen disables the two BIOS calls (for the e820 table >> and video initialization) that Xen would otherwise make. This has >> worked fine for all of the TXT systems that I am aware of and is likely >> due to TXT only being available on newer systems (with fewer issues in >> these areas). >> > Joe > > -----Original Message----- > From: Hal Finney [mailto:hal...@gm...] > Sent: Sunday, May 25, 2008 3:34 PM > To: Jun Koi > Cc: Cihula, Joseph; tbo...@li... > Subject: Re: [tboot-devel] How to validate the PCR measured by TXT? > > Hello Jun - > > On Thu, May 22, 2008 at 11:49 PM, Jun Koi <jun...@gm...> wrote: >> So basically the question is: should we execute other code outside our >> "trusted code"? In this example, BIOS code is not trusted. Or we >> should avoid that as much as we can? > > That certainly makes sense to me. There are really two points here. > The first is that we don't trust the BIOS because we don't know what > is in it. The TXT launch does not measure the BIOS and so the TXT PCRs > do not depend on BIOS contents. Any call we make to BIOS would run > code that could not be verified. > > The second point is that if we did originally do a measured boot, so > that PCR's 0-7 contain information about BIOS and other aspects of the > computer configuration, then if we made a call to BIOS, in principle > we could trust that. The verifier could check that the BIOS > configuration was as expected and if the BIOS was known to be trusted > by that verifier, the call would be OK. But there are still problems. > > One problem is the size of the Trusted Computer Base (TCB). Including > the whole BIOS into the TCB makes it larger (although I don't know how > the BIOS size will compare with Xen). Also, BIOSes often do not have > much transparency so it may be hard to get hold of the source code and > know what the BIOS is doing. Also, there are many different brands and > varieties of BIOS so it would be hard to trust very many of them. > Another point is that some BIOSes have not done measured boot properly > and it may be possible to reflash the BIOS to lie about the measured > boot. > > Part of the goal of TXT technology is to reduce the size of the TCB > and avoid dependence on measured boot. Avoiding calls into the BIOS > would be a good idea for any TXT Measured Launch Environment (MLE) > including Xen. However I don't know whether Xen has done as you > suggest, and avoids BIOS calls when in trusted mode. > > Hal Finney > > ------------------------------------------------------------------------ - > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > tboot-devel mailing list > tbo...@li... > https://lists.sourceforge.net/lists/listinfo/tboot-devel > > |