From: David Li <w.d...@gm...> - 2011-08-03 03:08:29
|
Hi, I am new to TPM and IMA. I followed the following instructions : http://linux-ima.sourceforge.net/ to compile the test code. I got the following error in running ima_measure: -bash-4.1# ./ima_measure /sys/kernel/security/tpm0/binary_bios_measurements --verbose ### PCR HASH TEMPLATE-NAME 0 000 08 00 00 00 29 8D F1 25 B2 60 EF 64 20 1B DF 08 15 C0 03 87248900926 ERROR: event name too long! Now I don't have a clue about the file name length 87248900926. Can anyone help to explain? Regards, David |
From: Mimi Z. <zo...@li...> - 2011-08-04 17:38:05
|
On Tue, 2011-08-02 at 20:08 -0700, David Li wrote: > Hi, > > I am new to TPM and IMA. I followed the following instructions : > > http://linux-ima.sourceforge.net/ > > to compile the test code. I got the following error in running > ima_measure: > > -bash-4.1# ./ima_measure /sys/kernel/security/tpm0/binary_bios_measurements --verbose > ### PCR HASH TEMPLATE-NAME > 0 000 08 00 00 00 29 8D F1 25 B2 60 EF 64 20 1B DF 08 15 C0 03 > 87248900926 ERROR: event name too long! > > Now I don't have a clue about the file name length 87248900926. > > Can anyone help to explain? The entire record is bogus. Is IMA enabled? The output should look something like: ### PCR HASH TEMPLATE-NAME 0 010 1A 44 67 C5 8D 55 4B 75 EB EF 6F 90 02 C4 EE E6 95 61 71 B5 ima 2A C8 DF A1 69 23 65 5E F1 A6 48 87 21 EB 9F 97 2C 23 F1 12 boot_aggregate Which kernel are you running (uname -r)? What boot command line parameters did you supply (cat /proc/cmdline)? thanks, Mimi |
From: David Li <w.d...@gm...> - 2011-08-04 17:56:22
|
Hi Mimi, My HS22 is running RHEL6: -bash-4.1# uname -r 2.6.32-131.6.1.el6.cs.x86_64 The machine is PXEBooted: -bash-4.1# cat /proc/cmdline initrd=initramfs-2.6.32-131.6.1.el6.cs.x86_64.img mem=8G root=<xyz> rw BOOT_IMAGE=vmlinuz-2.6.32-131.6.1.el6.cs.x86_64 Regards, David On Thu, Aug 4, 2011 at 10:37 AM, Mimi Zohar <zo...@li...>wrote: > On Tue, 2011-08-02 at 20:08 -0700, David Li wrote: > > Hi, > > > > I am new to TPM and IMA. I followed the following instructions : > > > > http://linux-ima.sourceforge.net/ > > > > to compile the test code. I got the following error in running > > ima_measure: > > > > -bash-4.1# ./ima_measure > /sys/kernel/security/tpm0/binary_bios_measurements --verbose > > ### PCR HASH TEMPLATE-NAME > > 0 000 08 00 00 00 29 8D F1 25 B2 60 EF 64 20 1B DF 08 15 C0 03 > > 87248900926 ERROR: event name too long! > > > > Now I don't have a clue about the file name length 87248900926. > > > > Can anyone help to explain? > > The entire record is bogus. Is IMA enabled? The output should look > something like: > ### PCR HASH TEMPLATE-NAME > 0 010 1A 44 67 C5 8D 55 4B 75 EB EF 6F 90 02 C4 EE E6 95 61 71 B5 ima 2A > C8 > DF A1 69 23 65 5E F1 A6 48 87 21 EB 9F 97 2C 23 F1 12 boot_aggregate > > Which kernel are you running (uname -r)? What boot command line > parameters did you supply (cat /proc/cmdline)? > > thanks, > > Mimi > > |
From: Mimi Z. <zo...@li...> - 2011-08-04 22:38:28
|
On Thu, 2011-08-04 at 10:55 -0700, David Li wrote: > Hi Mimi, > > > My HS22 is running RHEL6: > > > -bash-4.1# uname -r > 2.6.32-131.6.1.el6.cs.x86_64 > > > The machine is PXEBooted: > > > -bash-4.1# cat /proc/cmdline > initrd=initramfs-2.6.32-131.6.1.el6.cs.x86_64.img mem=8G root=<xyz> rw > BOOT_IMAGE=vmlinuz-2.6.32-131.6.1.el6.cs.x86_64 IMA is enabled in RHEL6 by default, but to collect measurements requires replacing the null policy with the TCB one, by specifying the 'ima_tcb' boot command line parameter. In addition, you might need to specify the 'ima=on' parameter as well. Instead of downloading the individual IMA test programs and the LTP 'glue' (eg. include files, definitions and stub functions) separately, the new ltp-ima-standalone tar file includes the IMA tests. (http://downloads.sf.net/project/linux-ima/linux-ima/ltp-ima-standalone.tar.gz) (The IMA LTP test programs require the openssl and openssl-devel packages.) thanks, Mimi |
From: David Li <w.d...@gm...> - 2011-08-05 00:57:23
|
Hi Mimi, I used your latest test code and added ima_tcb and ima=on to the kernel cmds. I still got the the same error. Any suggestions? - Thanks. -bash-4.1# ./ima_measure /sys/kernel/security/tpm0/binary_bios_measurements --verbose ### PCR HASH TEMPLATE-NAME 0 000 08 00 00 00 29 8D F1 25 B2 60 EF 64 20 1B DF 08 15 C0 03 87248900926 ERROR: event name too long! -bash-4.1# cat /proc/cmdline initrd=initramfs-2.6.32-131.6.1.el6.cs.x86_64.img mem=8G root=xyz rw ima_tcb ima=on BOOT_IMAGE=vmlinuz-2.6.32-131.6.1.el6.cs.x86_64 Regards, David On Thu, Aug 4, 2011 at 3:38 PM, Mimi Zohar <zo...@li...> wrote: > On Thu, 2011-08-04 at 10:55 -0700, David Li wrote: > > Hi Mimi, > > > > > > My HS22 is running RHEL6: > > > > > > -bash-4.1# uname -r > > 2.6.32-131.6.1.el6.cs.x86_64 > > > > > > The machine is PXEBooted: > > > > > > -bash-4.1# cat /proc/cmdline > > initrd=initramfs-2.6.32-131.6.1.el6.cs.x86_64.img mem=8G root=<xyz> rw > > BOOT_IMAGE=vmlinuz-2.6.32-131.6.1.el6.cs.x86_64 > > IMA is enabled in RHEL6 by default, but to collect measurements requires > replacing the null policy with the TCB one, by specifying the 'ima_tcb' > boot command line parameter. In addition, you might need to specify the > 'ima=on' parameter as well. > > Instead of downloading the individual IMA test programs and the LTP > 'glue' (eg. include files, definitions and stub functions) separately, > the new ltp-ima-standalone tar file includes the IMA tests. > ( > http://downloads.sf.net/project/linux-ima/linux-ima/ltp-ima-standalone.tar.gz > ) > (The IMA LTP test programs require the openssl and openssl-devel > packages.) > > thanks, > > Mimi > > > |
From: Mimi Z. <zo...@li...> - 2011-08-05 14:48:37
|
On Thu, 2011-08-04 at 17:56 -0700, David Li wrote: > > Hi Mimi, > > I used your latest test code and added ima_tcb and ima=on to the > kernel cmds. I still got the the same error. Any suggestions? - > Thanks. > > > -bash-4.1# ./ima_measure /sys/kernel/security/tpm0/binary_bios_measurements --verbose > ### PCR HASH TEMPLATE-NAME > 0 000 08 00 00 00 29 8D F1 25 B2 60 EF 64 20 1B DF 08 15 C0 03 > 87248900926 ERROR: event name too long! > > > -bash-4.1# cat /proc/cmdline > initrd=initramfs-2.6.32-131.6.1.el6.cs.x86_64.img mem=8G root=xyz rw > ima_tcb ima=on BOOT_IMAGE=vmlinuz-2.6.32-131.6.1.el6.cs.x86_64 > > Regards, > > > David Sorry, it's a bit confusing. There are two similarly named files /sys/kernel/security/tpm0/binary_bios_measurements and /sys/kernel/security/ima/binary_runtime_measurements. The input to ima_boot_aggregate is the first; the input to ima_measure is the latter. thanks, Mimi |
From: David Li <w.d...@gm...> - 2011-08-05 15:24:05
|
Hi Mimi, Yes, you are right. Now I got both. I think the first time IMA wasn't really enabled properly. SO I only saw tpm0 and no ima directory under /sys/kernel/security/. Now I see both. Thanks for the help. David On Friday, August 5, 2011, Mimi Zohar <zo...@li...> wrote: > On Thu, 2011-08-04 at 17:56 -0700, David Li wrote: >> >> Hi Mimi, >> >> I used your latest test code and added ima_tcb and ima=on to the >> kernel cmds. I still got the the same error. Any suggestions? - >> Thanks. >> >> >> -bash-4.1# ./ima_measure /sys/kernel/security/tpm0/binary_bios_measurements --verbose >> ### PCR HASH TEMPLATE-NAME >> 0 000 08 00 00 00 29 8D F1 25 B2 60 EF 64 20 1B DF 08 15 C0 03 >> 87248900926 ERROR: event name too long! >> >> >> -bash-4.1# cat /proc/cmdline >> initrd=initramfs-2.6.32-131.6.1.el6.cs.x86_64.img mem=8G root=xyz rw >> ima_tcb ima=on BOOT_IMAGE=vmlinuz-2.6.32-131.6.1.el6.cs.x86_64 >> >> Regards, >> >> >> David > > Sorry, it's a bit confusing. There are two similarly named > files /sys/kernel/security/tpm0/binary_bios_measurements > and /sys/kernel/security/ima/binary_runtime_measurements. The input to > ima_boot_aggregate is the first; the input to ima_measure is the latter. > > thanks, > > Mimi > > -- Regards, David |
From: David Li <w.d...@gm...> - 2011-08-05 19:13:43
|
Hi Mimi, A few more questions. Maybe this is because I am not familiar with the TPM specs. 1. For boot measurements, I don't quite understand the contents in tpm0/ascii_bios_measurements: ------------------------ -bash-4.1# cat ascii_bios_measurements 0 298df125b260ef64201bdf0815c003873eedd50e 08 [S-CRTM Version] 0 601c176e940570ac499814b48464e40e3ace1e24 80000008 [] 0 530983fd9caddb20e6f0da59e05f1c66b4d170c8 80000008 [] 2 753287ecae33ed00090081a45280a2b81777b7a5 80000004 [] 2 94c047a4256e04cccc99e43fdc6bb4c1cdef1ec3 80000004 [] 2 b3b175a24d63c62c2c64bfd66a4a0de41bef105b 80000004 [] 2 6b5a2268e60f5bdaa80f164f9e5d8bf88cb130c2 80000005 [] 2 6b5a2268e60f5bdaa80f164f9e5d8bf88cb130c2 80000005 [] 2 6b5a2268e60f5bdaa80f164f9e5d8bf88cb130c2 80000005 [] 2 6b5a2268e60f5bdaa80f164f9e5d8bf88cb130c2 80000005 [] <snip> The 1st col is the PCR#. Is the 2nd col the hash value corresponding to some BIOS executable or file? Why do some of them have the same hash value for the same PCR? What's the 3rd col? Are all BIOS boot measurements stored in PCR0-7? Which PCR stores the boot_aggregate hash value? 2. For run time measurements in /sys/kernel/security/ima/ascii_runtime_measurements: ---------------------------------------------------------------- 10 69d8e44453545591bedff7503598be62f0182cc6 ima ee3b9bfb435482e64a5fca0ea60f2d3de0698dd9 boot_aggregate 10 9ac8605fbbfa5d8ba909b635c7b7ad4a654a8eb5 ima 78cdc547d4a9930ad6e7880f18a496785538e13e /init 10 d0ac68b0927683a741efc10b886a76cb4c99926a ima b30285be1079de1138b669180955a3ba54e1ee84 /init 10 5c1abd04e37ae96ab0eea44ca8edb628c3053ae4 ima 06309cd5fae6e9bddc73cd2fe8f3e6167106c227 ld-2.12.so 10 516910c25617785536dd83ee8b621ce4a8097a0a ima d0960a31ea00318947d0e2d7b866dbda69d1dc88 ld.so.cache why do we need both template and filedata hash values? It seems ima_measure only uses the template hash value. My calculated PCRAggr (re-calculated): DE C7 CC ED 07 06 22 F0 C8 2D 95 2E A4 DE D5 AC F7 24 2B 99-bash-4.1# doesn't match -bash-4.1# cat /sys/devices/pnp0/00:09/pcrs | grep PCR-10 PCR-10: B0 C0 81 C2 93 A7 42 09 60 01 99 68 80 69 C2 E1 25 04 38 0C I noticed that in http://linux-ima.sourceforge.net/, it's /sys/devices/pnp0/00.0a/pcrs but in my case, "pcrs" in is in /sys/devices/pnp0/00.09/. Does this make a difference? Or maybe this is because the real-time measurement is continuously changing and being updated but the values in "pcrs" doesn't. Is this true? Thanks.and Regards, David On Fri, Aug 5, 2011 at 8:23 AM, David Li <w.d...@gm...> wrote: > Hi Mimi, > > Yes, you are right. Now I got both. > I think the first time IMA wasn't really enabled properly. SO I only saw > tpm0 and no ima directory under /sys/kernel/security/. > Now I see both. > > Thanks for the help. > > David > > > > On Friday, August 5, 2011, Mimi Zohar <zo...@li...> wrote: > > On Thu, 2011-08-04 at 17:56 -0700, David Li wrote: > >> > >> Hi Mimi, > >> > >> I used your latest test code and added ima_tcb and ima=on to the > >> kernel cmds. I still got the the same error. Any suggestions? - > >> Thanks. > >> > >> > >> -bash-4.1# ./ima_measure > /sys/kernel/security/tpm0/binary_bios_measurements --verbose > >> ### PCR HASH TEMPLATE-NAME > >> 0 000 08 00 00 00 29 8D F1 25 B2 60 EF 64 20 1B DF 08 15 C0 03 > >> 87248900926 ERROR: event name too long! > >> > >> > >> -bash-4.1# cat /proc/cmdline > >> initrd=initramfs-2.6.32-131.6.1.el6.cs.x86_64.img mem=8G root=xyz rw > >> ima_tcb ima=on BOOT_IMAGE=vmlinuz-2.6.32-131.6.1.el6.cs.x86_64 > >> > >> Regards, > >> > >> > >> David > > > > Sorry, it's a bit confusing. There are two similarly named > > files /sys/kernel/security/tpm0/binary_bios_measurements > > and /sys/kernel/security/ima/binary_runtime_measurements. The input to > > ima_boot_aggregate is the first; the input to ima_measure is the latter. > > > > thanks, > > > > Mimi > > > > > > -- > Regards, > > David > > |
From: Seiji M. <sei...@gm...> - 2011-08-09 19:42:21
|
On Sat, Aug 6, 2011 at 4:13 AM, David Li <w.d...@gm...> wrote: > 1. For boot measurements, I don't quite understand the contents in > tpm0/ascii_bios_measurements: > ------------------------ > -bash-4.1# cat ascii_bios_measurements > 0 298df125b260ef64201bdf0815c003873eedd50e 08 [S-CRTM Version] > 0 601c176e940570ac499814b48464e40e3ace1e24 80000008 [] > 0 530983fd9caddb20e6f0da59e05f1c66b4d170c8 80000008 [] > 2 753287ecae33ed00090081a45280a2b81777b7a5 80000004 [] > 2 94c047a4256e04cccc99e43fdc6bb4c1cdef1ec3 80000004 [] > 2 b3b175a24d63c62c2c64bfd66a4a0de41bef105b 80000004 [] > 2 6b5a2268e60f5bdaa80f164f9e5d8bf88cb130c2 80000005 [] > 2 6b5a2268e60f5bdaa80f164f9e5d8bf88cb130c2 80000005 [] > 2 6b5a2268e60f5bdaa80f164f9e5d8bf88cb130c2 80000005 [] > 2 6b5a2268e60f5bdaa80f164f9e5d8bf88cb130c2 80000005 [] > <snip> > > The 1st col is the PCR#. > > Is the 2nd col the hash value corresponding to some BIOS executable or > file? Why do some of them have the same hash value for the same PCR? > > What's the 3rd col? > > Are all BIOS boot measurements stored in PCR0-7? yes. It seems this is EFI BIOS. 3rd col means: 80000008 EV_EFI_PLATFORM_FIRMWARE_BLOB 80000004 EV_EFI_BOOT_SERVICES_DRIVER 80000005 EV_EFI_RUNTIME_SERVICES_DRIVER The detail described by "TCG EFI Platform Specification" at http://www.trustedcomputinggroup.org/resources/tcg_efi_platform_specification_version_120_revision_10 -- Seiji |
From: Mimi Z. <zo...@li...> - 2011-08-08 16:01:38
|
On Fri, 2011-08-05 at 12:13 -0700, David Li wrote: > Hi Mimi, > > A few more questions. Maybe this is because I am not familiar with the > TPM specs. > > 1. For boot measurements, I don't quite understand the contents in > tpm0/ascii_bios_measurements: > ------------------------ > -bash-4.1# cat ascii_bios_measurements > 0 298df125b260ef64201bdf0815c003873eedd50e 08 [S-CRTM Version] > 0 601c176e940570ac499814b48464e40e3ace1e24 80000008 [] > 0 530983fd9caddb20e6f0da59e05f1c66b4d170c8 80000008 [] > 2 753287ecae33ed00090081a45280a2b81777b7a5 80000004 [] > 2 94c047a4256e04cccc99e43fdc6bb4c1cdef1ec3 80000004 [] > 2 b3b175a24d63c62c2c64bfd66a4a0de41bef105b 80000004 [] > 2 6b5a2268e60f5bdaa80f164f9e5d8bf88cb130c2 80000005 [] > 2 6b5a2268e60f5bdaa80f164f9e5d8bf88cb130c2 80000005 [] > 2 6b5a2268e60f5bdaa80f164f9e5d8bf88cb130c2 80000005 [] > 2 6b5a2268e60f5bdaa80f164f9e5d8bf88cb130c2 80000005 [] > <snip> > > The 1st col is the PCR#. yes > Is the 2nd col the hash value corresponding to some BIOS executable or > file? Why do some of them have the same hash value for the same PCR? Yes, this is the hash. I'll defer to others on the mailing list about the BIOS measurement specifics. > What's the 3rd col? > > Are all BIOS boot measurements stored in PCR0-7? > Which PCR stores the boot_aggregate hash value? PCR 0 - 7 are stored in the IMA boot aggregate. > 2. For run time measurements > in /sys/kernel/security/ima/ascii_runtime_measurements: > ---------------------------------------------------------------- > 10 69d8e44453545591bedff7503598be62f0182cc6 ima > ee3b9bfb435482e64a5fca0ea60f2d3de0698dd9 boot_aggregate > 10 9ac8605fbbfa5d8ba909b635c7b7ad4a654a8eb5 ima > 78cdc547d4a9930ad6e7880f18a496785538e13e /init > 10 d0ac68b0927683a741efc10b886a76cb4c99926a ima > b30285be1079de1138b669180955a3ba54e1ee84 /init > 10 5c1abd04e37ae96ab0eea44ca8edb628c3053ae4 ima > 06309cd5fae6e9bddc73cd2fe8f3e6167106c227 ld-2.12.so > 10 516910c25617785536dd83ee8b621ce4a8097a0a ima > d0960a31ea00318947d0e2d7b866dbda69d1dc88 ld.so.cache > > why do we need both template and filedata hash values? It seems > ima_measure only uses the template hash value. The template hash is the hash of the template data, which includes the file hash and other file metadata. Templates, originally introduced with the Linux Integrity Module, extended the IMA infrastructure to attest to data other than file measurements, but for lack of users, was not upstreamed. ima-ng and ima-nglong are two proposed templates ima-ng and ima-nglong. ima-ng adds support for different hash algorithms, while ima-nglong adds the object uid, gid, and LSM object and subject labels. For a description of these templates, refer to http://sourceforge.net/mailarchive/forum.php?thread_name=1275914594-8808-5-git-send-email-zohar%40linux.vnet.ibm.com&forum_name=linux-ima-user > My calculated PCRAggr (re-calculated): DE C7 CC ED 07 06 22 F0 C8 2D > 95 2E A4 DE D5 AC F7 24 2B 99-bash-4.1# > doesn't match > -bash-4.1# cat /sys/devices/pnp0/00:09/pcrs | grep PCR-10 > PCR-10: B0 C0 81 C2 93 A7 42 09 60 01 99 68 80 69 C2 E1 25 04 38 0C If the measurement list is invalidated (<securityfs>/ima/violations), then it purposely doesn't match. To validate the measurement list, which contain invalidations, add the '--validate' option. > I noticed that in http://linux-ima.sourceforge.net/, > it's /sys/devices/pnp0/00.0a/pcrs but in my case, "pcrs" in is > in /sys/devices/pnp0/00.09/. Does this make a difference? No, it shouldn't make a difference. > Or maybe this is because the real-time measurement is continuously > changing and being updated but the values in "pcrs" doesn't. Is this > true? > > Thanks.and Regards, > > > David Where the PCRs are located, has nothing to do with the runtime measurements. thanks, Mimi |
From: Rajiv A. <sr...@li...> - 2011-08-09 03:15:56
|
Maybe I can help with the first section: On 08-08-2011 13:01, Mimi Zohar wrote: > On Fri, 2011-08-05 at 12:13 -0700, David Li wrote: >> Hi Mimi, >> >> A few more questions. Maybe this is because I am not familiar with the >> TPM specs. >> >> 1. For boot measurements, I don't quite understand the contents in >> tpm0/ascii_bios_measurements: >> ------------------------ >> -bash-4.1# cat ascii_bios_measurements >> 0 298df125b260ef64201bdf0815c003873eedd50e 08 [S-CRTM Version] >> 0 601c176e940570ac499814b48464e40e3ace1e24 80000008 [] >> 0 530983fd9caddb20e6f0da59e05f1c66b4d170c8 80000008 [] >> 2 753287ecae33ed00090081a45280a2b81777b7a5 80000004 [] >> 2 94c047a4256e04cccc99e43fdc6bb4c1cdef1ec3 80000004 [] >> 2 b3b175a24d63c62c2c64bfd66a4a0de41bef105b 80000004 [] >> 2 6b5a2268e60f5bdaa80f164f9e5d8bf88cb130c2 80000005 [] >> 2 6b5a2268e60f5bdaa80f164f9e5d8bf88cb130c2 80000005 [] >> 2 6b5a2268e60f5bdaa80f164f9e5d8bf88cb130c2 80000005 [] >> 2 6b5a2268e60f5bdaa80f164f9e5d8bf88cb130c2 80000005 [] >> <snip> >> >> The 1st col is the PCR#. > yes > >> Is the 2nd col the hash value corresponding to some BIOS executable or >> file? Why do some of them have the same hash value for the same PCR? > Yes, this is the hash. I'll defer to others on the mailing list about > the BIOS measurement specifics. It doesn't happen here, maybe the bios is registering such events duplicated by mistake? Can you send us the binary blob of such event log (binary_bios_measurements)? >> What's the 3rd col? The event type, according to tpm_bios.c: enum tcpa_event_types { PREBOOT = 0, POST_CODE, UNUSED, NO_ACTION, SEPARATOR, ACTION, EVENT_TAG, SCRTM_CONTENTS, SCRTM_VERSION, CPU_MICROCODE, PLATFORM_CONFIG_FLAGS, TABLE_OF_DEVICES, COMPACT_HASH, IPL, IPL_PARTITION_DATA, NONHOST_CODE, NONHOST_CONFIG, NONHOST_INFO, }; It's odd though that there's a high bit being set for some of them, the same doesn't happen here. After looking at the binary log we can say who's the culprit, tpm_bios or the bios itself setting the event log incorrectly, and then come up with a workaround. Rajiv |
From: David Li <w.d...@gm...> - 2011-08-14 00:30:18
|
Hi Rajiv, Sorry I have been away from office. I 'll send you the binaries once I get back in next week. Regards, David On Mon, Aug 8, 2011 at 7:45 PM, Rajiv Andrade <sr...@li...>wrote: > Maybe I can help with the first section: > > On 08-08-2011 13:01, Mimi Zohar wrote: > > On Fri, 2011-08-05 at 12:13 -0700, David Li wrote: > >> Hi Mimi, > >> > >> A few more questions. Maybe this is because I am not familiar with the > >> TPM specs. > >> > >> 1. For boot measurements, I don't quite understand the contents in > >> tpm0/ascii_bios_measurements: > >> ------------------------ > >> -bash-4.1# cat ascii_bios_measurements > >> 0 298df125b260ef64201bdf0815c003873eedd50e 08 [S-CRTM Version] > >> 0 601c176e940570ac499814b48464e40e3ace1e24 80000008 [] > >> 0 530983fd9caddb20e6f0da59e05f1c66b4d170c8 80000008 [] > >> 2 753287ecae33ed00090081a45280a2b81777b7a5 80000004 [] > >> 2 94c047a4256e04cccc99e43fdc6bb4c1cdef1ec3 80000004 [] > >> 2 b3b175a24d63c62c2c64bfd66a4a0de41bef105b 80000004 [] > >> 2 6b5a2268e60f5bdaa80f164f9e5d8bf88cb130c2 80000005 [] > >> 2 6b5a2268e60f5bdaa80f164f9e5d8bf88cb130c2 80000005 [] > >> 2 6b5a2268e60f5bdaa80f164f9e5d8bf88cb130c2 80000005 [] > >> 2 6b5a2268e60f5bdaa80f164f9e5d8bf88cb130c2 80000005 [] > >> <snip> > >> > >> The 1st col is the PCR#. > > yes > > > >> Is the 2nd col the hash value corresponding to some BIOS executable or > >> file? Why do some of them have the same hash value for the same PCR? > > Yes, this is the hash. I'll defer to others on the mailing list about > > the BIOS measurement specifics. > It doesn't happen here, maybe the bios is registering such events > duplicated by mistake? Can you send us the binary blob of such event log > (binary_bios_measurements)? > >> What's the 3rd col? > The event type, according to tpm_bios.c: > > enum tcpa_event_types { > PREBOOT = 0, > POST_CODE, > UNUSED, > NO_ACTION, > SEPARATOR, > ACTION, > EVENT_TAG, > SCRTM_CONTENTS, > SCRTM_VERSION, > CPU_MICROCODE, > PLATFORM_CONFIG_FLAGS, > TABLE_OF_DEVICES, > COMPACT_HASH, > IPL, > IPL_PARTITION_DATA, > NONHOST_CODE, > NONHOST_CONFIG, > NONHOST_INFO, > }; > > It's odd though that there's a high bit being set for some of them, the > same doesn't happen here. After looking at the binary log we can say who's > the culprit, tpm_bios or the bios itself setting the event log incorrectly, > and then come up with a workaround. > > Rajiv > > |
From: David Li <w.d...@gm...> - 2011-08-19 20:49:31
|
Hi Rajiv, One thing just occurred to me: My machine was PXEbooted and diskless. Is this supported in trusted boot measurement list? Regards, David On Mon, Aug 8, 2011 at 7:45 PM, Rajiv Andrade <sr...@li...>wrote: > Maybe I can help with the first section: > > On 08-08-2011 13:01, Mimi Zohar wrote: > > On Fri, 2011-08-05 at 12:13 -0700, David Li wrote: > >> Hi Mimi, > >> > >> A few more questions. Maybe this is because I am not familiar with the > >> TPM specs. > >> > >> 1. For boot measurements, I don't quite understand the contents in > >> tpm0/ascii_bios_measurements: > >> ------------------------ > >> -bash-4.1# cat ascii_bios_measurements > >> 0 298df125b260ef64201bdf0815c003873eedd50e 08 [S-CRTM Version] > >> 0 601c176e940570ac499814b48464e40e3ace1e24 80000008 [] > >> 0 530983fd9caddb20e6f0da59e05f1c66b4d170c8 80000008 [] > >> 2 753287ecae33ed00090081a45280a2b81777b7a5 80000004 [] > >> 2 94c047a4256e04cccc99e43fdc6bb4c1cdef1ec3 80000004 [] > >> 2 b3b175a24d63c62c2c64bfd66a4a0de41bef105b 80000004 [] > >> 2 6b5a2268e60f5bdaa80f164f9e5d8bf88cb130c2 80000005 [] > >> 2 6b5a2268e60f5bdaa80f164f9e5d8bf88cb130c2 80000005 [] > >> 2 6b5a2268e60f5bdaa80f164f9e5d8bf88cb130c2 80000005 [] > >> 2 6b5a2268e60f5bdaa80f164f9e5d8bf88cb130c2 80000005 [] > >> <snip> > >> > >> The 1st col is the PCR#. > > yes > > > >> Is the 2nd col the hash value corresponding to some BIOS executable or > >> file? Why do some of them have the same hash value for the same PCR? > > Yes, this is the hash. I'll defer to others on the mailing list about > > the BIOS measurement specifics. > It doesn't happen here, maybe the bios is registering such events > duplicated by mistake? Can you send us the binary blob of such event log > (binary_bios_measurements)? > >> What's the 3rd col? > The event type, according to tpm_bios.c: > > enum tcpa_event_types { > PREBOOT = 0, > POST_CODE, > UNUSED, > NO_ACTION, > SEPARATOR, > ACTION, > EVENT_TAG, > SCRTM_CONTENTS, > SCRTM_VERSION, > CPU_MICROCODE, > PLATFORM_CONFIG_FLAGS, > TABLE_OF_DEVICES, > COMPACT_HASH, > IPL, > IPL_PARTITION_DATA, > NONHOST_CODE, > NONHOST_CONFIG, > NONHOST_INFO, > }; > > It's odd though that there's a high bit being set for some of them, the > same doesn't happen here. After looking at the binary log we can say who's > the culprit, tpm_bios or the bios itself setting the event log incorrectly, > and then come up with a workaround. > > Rajiv > > |